Сетевой метод автоматизации высоковакуумной установки для получения сверхтонких пленок на базе Linux

Автоматизация процесса получения сверхтонких пленок, основанная на использовании технологии молекулярно-лучевой эпитаксии (МЛЭ), облегчает как сам длительный по времени технологический процесс, так и обработку его результатов. Базовый комплект установки «Ангара» [1], разработанной в 1980-е гг. в Институте физики полупроводников Сибирского отделения Российской академии наук (Новосибирск) под руководством С. И. Стенина, не достаточно автоматизирован для технологических потребностей современного эксперимента [2], особенно если учесть темпы научно-технического прогресса последних лет в области вычислительной техники [3. С. 16]. От выбранного метода применения компьютерных технологий во многом будут зависеть возможности проведения экспериментов, дальнейшие перспективы их развития, долговечность и эффективность используемого оборудования, возможность внедрения данного метода, т. е. использование его принципов на других подобных установках [4]. Таким образом, выбор метода является важным аспектом в разработке систем автоматизации. Сопоставив критерии эффективности [5. С. 4] (такие, как надежность, точность, быстродействие, стоимость и т. д.); авторы выбрали сетевой метод автоматизации. Работа выполнялась по типу интенсивного развития системы [3], т. е. направлена на совершенствование структуры системы, оптимизацию ее функционирования, создание условий для типовых проектных решений.

Основа сетевого метода. Конечные терминалы для пользователя обычно было принято располагать на Windows-платформах. Однако для обеспечения стабильного и непрерывного выполнения технологической операции напыления основная часть программного обеспечения реализована на компьютере, работающем в операционной системе Linux (Linux-сервер). Система адаптирована для удаленного (сетевого) управления установкой с детальным разграничением прав доступа. Высокая надежность и открытая архитектура Linux [6] позволяет внедрять новые способы интерактивной связи с установкой: задание сценариев нагрева и напыления посредством глобальных сетей, мобильной связи и т. д. К тому же прогрессирование Windows-платформ связано с перестроением кодов или технологий. Серверная же программа не требует модернизации, так как механизмы взаимодействия с терминалами остаются неизменными. Изменению следует подвергнуть лишь не большие Windows-модули, выполняющие терминальную функцию визуализации.

Сервер обменивается информацией с блоком управления через последовательный (СОМ) порт. Блок управления представляет собой программно-аппаратный комплекс, соединяющий программную среду Linux-серве -ра с аппаратной средой установки при помощи аналого-цифровых и цифро-аналоговых преобразователей, а также однокристального микропроцессора Atmel AT89S8252 [2].

Микропроцессорная техника широко используется для создания высокоэффективных систем автоматизации технологическими процессами [7]. Программы микропроцессора и Linux-сервера взаимодействуют по определенному протоколу передачи байтов данных, где отдельному байт-коду, переданному с сервера, соответствует команда для аппаратной части установки. Таким образом, с помощью программного интерфейса HaLinux-cep-вере (либо клиентских приложений, взаимодействующих с ним) осуществляется полный процесс напыления, включая контроль результатов (рис. 1).

Win dows-клиенты

Рис. 1. Схема соединения модулей системы управления

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

Для написания кода программы применяются потоки выполнения, определенные в стандарте POSIX. 1с [8]. Чтобы решить проблемы синхронизации, т. е. взаимного использования глобальных и статических переменных, в POSIX. 1с можно использовать следующие объекты: взаимоисключающие блокировки (при попытке нескольких потоков установить блокировку успеха достигает лишь один из них); условные переменные (блокировка потока до выполнения определенных условий); семафоры (если поток пытается уменьшить значение семафора до отрицательного числа, то этот поток блокируется до тех пор, пока другой поток не увеличит значение семафора до неотрицательного значения). В нашем случае достаточно взаимоисключающих блокировок.

Серверная программа состоит из четырех основных функций (рис. 2):

• -    portsettingschanger - функции настройки последовательного порта. Она выполняется первостепенно и в случае ошибочного завершения, которое свидетельствует об аппаратных проблемах, останавливает программу. Используется неканонический (Raw) ввод и вывод данных на скорости 9 600 бод;

• -    temperaturereceiver - единственную функцию по получению данных с установки. Она опрашивает раз в 1 с регистры кварцевых измерителей толщины и термопар испарителей;

• -    evaporator heating и dampcrcomandcr - функций, схожих по принципу и предназначенных для нагрева испарителей и управления процессом напыления соответственно. Обе состоят из блока чтения (анализа) входных файлов-сценариев и блока непосредственной реализации данных сценариев. Особенностью функции dampcr comandcr является возможность как одновременного напыления нескольких материалов (multireader, multievaporation), так и последовательного напыления. В свою очередь из функции evaporator heating запускается множество потоков (channelchooserx, где х - порядковый номер канала) для обособленного нагрева каждого испарителя.

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

В серверной программе определена глобальная константа, указывающая на общее количество испарителей. В трехкамерной установке МЛЭ «Ангара» эта константа может принимать значения либо 6, либо 2 в зависимости от технологической камеры. Подобные константы дают большую гибкость программному продукту, так как для автоматизации другого оборудования МЛЭ потребуются минимальные изменения кода программы.

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

| р о rtsetti n gsch anger]

| ternperaturereceiver

| dampercommander]   |evaporator heating]

channel chooser x] | heating fiIe re a d er] |heating_start| |heatingstring cheeker| I bytesender]

filereader| |rnultireader

|string checker|

evaporationstart

|string checker|

।    \ ________ |m u Itieva p о rati о n]

Ibvte sender! rr .   '   ,—n

LJ—=------1 Ibytesenderl

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

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

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