При разработке систем управления гибкими производственными системами (ГПС) необходимо учитывать возможные нештатные ситуации, возникающие на объекте управления. Такими ситуациями могут быть, например, отказ части оборудования, поломка, недостаток или неисправность инструментов и спутников для обработки деталей, организационные упущения или ошибки обслуживающего персонала. Для реальной производственной системы количество подобных ситуаций чрезвычайно велико. Для живучести системы управления необходимо учитывать эти ситуации при ее обработке.
В реальных системах управления ГПС до 85% общего объема программного обеспечения приходится на обработку и выход их нештатных ситуаций. Это негативно сказывается на сроках и стоимости разработки.
Наличие заранее предопределенных алгоритмов обработки нештатных ситуаций делает систему управления ГПС весьма жесткой, с трудом поддающейся изменению и обучению. Учитывая перспективы развития вычислительной техники и программных средств становится понятным, что такая структура системы управления неизбежно войдет в противоречие с нарождающимися методами искусственного интеллекта.
Альтернативным решением представляется концепция такой системы управления, которая могла бы легко изменяться и подстраиваться не только под конкретный объект управления, но даже под текущую ситуацию на этом объекте. Тогда отпадает необходимость обработки системой управления большинства нештатных ситуаций, т.к. для такой системы управления все возникаюшие ситуации являются вполне штатными, важна лишь настройка системы управления на эти ситуации. Настройка могла бы осуществляться автоматически для наиболее распрастраненных ситуаций или человеком - оператором, для более редких.
Построение такой системы управления подразумевает наличие определенных свойств у операционно-вычислительной среды, в которой эта система управления должна функционировать.
Способность к развитию. Операционно-вычислительная среда должна разрешать легкое изменение и развитие системы управления. По своей сути легкость изменения и развития очень созвучна с концепцией объектно-ориентированного программированния (ООП), предусматривающей три основных тринципа: инкапсуляцию, полиморфизм и наследуемость. Можно показать, что операционно-вычислительная среда обладающая всеми этими принципами в полной мере пригодна для обеспечения.
Интерактивность. Для обеспечения необходимой гибкости управления и саморазвития системы в процессе ее работы, система управления должна легко изменяться оператором с пульта управления или специальной программой Учителем. Важной особенностью является именно возможность изменения самой системы управления в процессе ее работы. Такое возможно при интерактивном построении операционно-вычислительной среды, используя интерпритатор как аппарат реализации. На практике, большинство используюших методы ООП алгоритмических языков, реализуют чисто компиляторный подход, что не пригодно для разработки систем управления по предлагаемой концепции, поскольку изменения программ системы управления во время работы несовместимо с их перекомпиляцией.
Кроме способности реализовывать ООП и интерпритационного характера среды неизбежно появляется ряд новых требований.
Многопроцессность. Далее будет показано, реализация методов ООП для интерпритатора легко может быть реализована механизмом создания и обслуживания параллельных прцессов в среде.
На рисунке 1 приведена типовая структура системы управления, иснользующая методы искуственного интеллекта.

Рис. 1. Типовая структура интеллектальной системы управления

Основу системы управления составляет управляющая система, которая использует для управления объектом информацию о его состоянии, полученную от датчиков и внутреннюю информацию из базы данных (знаний). Важным моментом при переходе к управлению с элементами искусственного интеллекта является использование базы знаний, которая хранит не только данные о состоянии объекта управления, но и продукции - правила работы с этими данными.
При традиционной структуре систем с элементами искусственного интеллекта обучение системы обычно ограничивается лишь воздействием на базу знаний, оставляя управляюшую часть системы управления неизменной. Рассматриваемый в данной работе подход не вводит каких-либо ограничений. Предполагается, что Учитель может изменять во время ее работы не только базу знаний, но и управляюшую систему.
При этом косвенно предполагается наличие нескольких одновременно функционирующих процессоров, одним из которых может быть процессор функционированния Учителя, другим - терминальный процесс обмена информацией с оператором, а также ряд процессов, осуществляющих прием и передачу информации на объект управления, обслуживание базы знаний, и конечно процессы реализующие работу управляющей системы. Вполне естественным становится условие многопроцессности, которое уже обсуждалось ранее.
Существует существенное различие между многопроцессностью и многозначностью как это понимается в операционных системах. При рассмотрении вопросов многозначности в операцинных системах предполагается и обеспечивается изоляция одного процесса от других. Каждый процесс функционирует в своей виртуальной вычислительной среде, не желая ничего знать о других не связанных с ним прцессах, выполняемых в тоже время на том же оборудовании. Если одной из задач необходимо взаимодействовать с другими, то обычно в операционных системах существуют свои методы, в частности, аппарат почтовых ящиков, куда одна из задач "кладет" свое сообщение, а другая задача его "вынимает".
Многопроцесность в нашем понимании нечто другое. То что правильно оправдано и обосновано для операционных систем, явно не оптимально для рассматриваемой операционно-вычислительной среды. Необходимо, чтобы с изоляцией одного процесса от другого была предусмотрена возможность изменения одного процесса другими. Будем называть такие процессы смежными. Смежные процессы не изолированы друг от друга, наоборот, оба процесса функционируют на одной общей виртуальной машине, т.е. имеют общую оперативную и дисковую память, и как бы выполняются двумя параллельными процессорами.
С многопроцессностью операционно-вычислительной среды тесно связана и реализация методов ООП. Классическая схема реализации ООП связана с процессом компиляции исходного текста програмного модуля. Традиционный подход не приемлем, когда речь идет об интерактивных языках, где компиляция принципиально исключена. В связи с этим, многопроцессность может явиться механизмом раелизации методов ООП.
Создание нового класса данных в объектно-ориентированной программе связан не только с созданием нового шаблона структуры данных, но и с образованием одного или нескольких новых процессов в нашей операционно-вычислительной среде. Каждый из таких процессов мог бы реализовать одну или несколько операций на вновь создаваемом классе данных. Отметим, что процессы создаются в момент объявления (описания) нового класса, хотя фактически могут использоваться только после определения (создания) объекта этого класса. Резервирование оперативной памяти производится под объекты класса, а не под сам класс. Таким образом достаточно просто реализовать принципы ООП: инкапсуляцию, полиморфизм и наследуемость.
Реализация инкапсуляции связывается с хранением в "капсуле" наряду с данными имени (или имен) процесса (процессов), которые обслуживают данный класс. Столь же просто реализуется наследуемость и полиморфизм, когда использование ранее определенных операций или их переопределение осуществляется с помощью создания или замены ссылок на существующие в среде процессы. На рис. 2 приведены основные схемы реализации объектно-ориентированного расширения языка.
Необходимо отметить, что с точки зрения вичислительной среды процессы различаются не только как изолированные и смежные, но и по времени их жизни. Если под временем жизни понимать период времени от момента порождения процесса до его закрытия, то существует разница между процессами. Примерами таких процессов могут служить управляющие процессы.
В то же время, процессы, реализующие ООП, хотя и присутствуют, но функционируют не все время жизни. Они начинают функционировать лишь тогда, когда необходима обработка соответствующего им объекта, после окончания которой они снова находятся в "спящем" состоянии. Такой подход накладывает особые требования на супервизор процессов операционно-вычислительной среды. С увеличением количества новых типов (классов) данных, увеличивается и количество процессов, эти данные обрабатывающие. Для реальной системы управления, количество процессов может измеряться сотнями и тысячами.
Такой подход накладывает особые требования на супервизор процессов операционно-вычислительной среды. С увеличением количества новых типов (классов) данных, увеличивается количество процессов, эти данные обрабатываются. Для реальной системы управления количество процессов может измеряться сотнями и тысячами.

Рис. 2. Структура организации расширения языка.

Основу рассматриваемой операционно-вычислительной среды составляют три основных блока (рис. 3):

базовый интерпритатор; интерпритатор расширения; супервизор процессов;

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

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


Рис. 3 Структура операционно - вычислительной среды.

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

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

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

Автор Кабак И.С.