CC BY
45
ГТД на основе НС являются вполне приемлимыми для применения на практике.
Комбинированный анализ информативности факторов на основе НС и коэффициентов корреляции позволяет упростить и оптимизировать модель коэффициента упрочнения, а также повысить достоверность получаемых результатов.
ПЕРЕЧЕНЬ ССЫЛОК
1. Яценко В. К., Зайцев Г. 3, Притченко В. Ф. и др. Повышение несущей способности деталей машин алмазным выглаживанием. - М.: Машиностроение, 1985. - 232 с.
2. Богуслаев В. А., Яценко В. К., Притченко В. Ф. Технологическое обеспечение и прогнозирование несущей способности деталей ГТД. - К.: Манускрипт, 1993. - 333 с.
3. Хайкин С. Нейронные сети: полный курс, 2-е издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2006. -1104 с.
4. Оссовский С. Нейронные сети для обработки информации / Пер. с польского. - М.: Финансы и статистика, 2004. - 344 с.
5. Патент № 44662А Укра'ша. Споаб визначення коеф1-ц1-ента змщнення деталей пюля алмазного вигладжування / Богуслаев О. В., Дубровш В. ¡., Субботш С. О., Сцен-ко В. К. Заявлено 16. 10. 2001 р. Опубл. 15.02.2002 р., бюл. № 2 «Промислова власшсть». - 6 с.
Надшшла 10.02.06
Розглянуто розв'язок 3adaui прогнозування коефщ^ ента змщнення на оcновi нейтронно'1 мереж-i. Розроблено алгоритмы, що дозволяють здшснювати ощнку iнфоpма-muemcmi та вiдбip тформативних nаpаметpiв.
The solution of a problem of hardening coefficient forecasting on the basic of neural networks is considered. The algorithms allowing to execute valuation of selfdescriptive-ness and selection of informative parameters are developed.
УДК 519.713:681.326
Г. Ф. Кривуля, О. С. Коробко, А. И. Липчанский, Д. Е. Шуклин
ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ЭКСПЕРТНОЙ СИСТЕМЫ НА БАЗЕ СЕМАНТИЧЕСКОЙ НЕЙРОННОЙ СЕТИ ДЛЯ ДИАГНОСТИКИ
КОМПЬЮТЕРНЫХ СЕТЕЙ
В работе рассматривается возможность применения экспертной системы на базе нейронной сети в целях диагностики компьютерной сети. Предлагается программное построение нейронной сети в виде многоуровневой системы. Каждый уровень указанной системы представляется совокупностью классов и методов, осуществляющих требуемые преобразования данных.
ВВЕДЕНИЕ
На сегодняшний день экспертные системы (ЭС) широко применяются для решения значительного класса разнообразных задач. Как правило, в случае отсутствия каких-либо четких алгоритмов поиска решения либо в случае, когда найденное некоторыми алгоритмами решение является неудовлетворительным, использование ЭС является целесообразным. ЭС традиционно применяются в целях интерпретации данных, диагностики, мониторинга, проектирования, прогнозирования, планирования, обучения.
В данной работе рассмотрено использование ЭС, построенной на базе семантической нейронной сети (НС), для диагностики компьютерных систем и сетей [1]. В представленной работе приводится подробное
© Кривуля Г. Ф., Коробко О. С., Липчанский А. И., Шуклин Д. Е., 2006
описание архитектуры НС, лежащей в основе ЭС, а также программная реализация ее структуры.
НС можно рассматривать как распределенную вычислительную систему, в которой нейроны соответствуют отдельным процессорам, а связи между нейронами соответствуют каналам передачи данных между этими процессорами. Подробное описание архитектуры нейрона в семантических НС приведено в работе [2].
1 ПОСТАНОВКА ЗАДАЧИ
Авторами была разработана виртуальная машина, позволяющая моделировать различные НС в среде последовательной вычислительной системы. Компонентная архитектура ядра данной виртуальной машины рассматривается в работе [3]. В связи с широким распространением объектно-ориентированных методов разработки программного обеспечения представляется рациональным реализовать уровень НС в виде объектно-ориентированной базы данных (ООБД). Нейроны реализованы объектами, а связи между нейронами реализованы как ссылки между объектами. Для обеспечения максимальной гибкости перенастройки системы
виртуальная машина реализована в виде нескольких уровней, связанных друг с другом через четко определенные интерфейсы.
Основная цель данной разработки - создание виртуальной машины, поддерживающей нейронные сети со свободной топологией и числом нейронов до 2 млрд. в одном хранилище. Данная возможность обеспечивается путем реализации системы управления сетевой объектно-ориентированной базы знаний (СООБЗ). Поэтому только часть объектов находится в данный момент в оперативной памяти. Большая часть объектов содержится в файловом хранилище.
Система управления сетевой объектно-ориентированной базой знаний должна обладать следующими возможностями:
- сохранять текущее состояние графа объектов или нейронной сети в СООБЗ между сеансами работы с пользователем. В том числе сохраняется текущая топология сети объектов. При повторном запуске приложения не понадобится создавать сеть объектов заново;
- при большем количестве экземпляров объектов ограничивать объем памяти, используемый графом объектов или нейронной сетью. Наиболее часто используемые объекты остаются в оперативной памяти, остальные вытесняются в файловое хранилище и загружаются в оперативную память по мере необходимости. При загрузке экземпляра в оперативную память он вытесняет другие, редко используемые объекты.
Ограничение объема памяти позволяет избавиться от использования файла подкачки операционной системы, что значительно повышает производительность моделирования сетей с большим количеством экземпляров объектов (при суммарном размере всех экземпляров большем, чем размер текущей свободной памяти в системе).
В случае, если объем сети объектов меньше чем размер текущей свободной памяти в системе, вся сеть находится в оперативной памяти и потерь производительности, связанных с сериализацией-десериализацией, не возникает.
Применение СООБЗ не накладывает никаких ограничений на используемую бизнес логику или математическую модель нейрона, которую можно реализовать как методы объектов, находящихся в СООБЗ. Основное требование - организовать связи между объектами в сети не с помощью указателей, а с помощью идентификаторов объектов. При этом будет необходимо получать указатель на объект, используя API СООБЗ.
2 РЕАЛИЗАЦИЯ ВЫЧИСЛИТЕЛЬНОЙ
СИСТЕМЫ
Виртуальная машина, реализующая преобразование абстракций нейронной сети в абстракции операционной системы реализована в виде многоуровневой
системы [4]. Каждый уровень представлен набором функций Application Programming Interface. Совокупность API всех уровней виртуальной машины, для определенности, названа Virtual Neural Programming Interface, далее VNPI. Ядро VNPI имеет 4 уровня: System Resource Manager (SRM) - уровень интерфейсов операционной системы; Virtual Memory Manager (VMM) - уровень управления памятью и сборщик мусора. Virtual Cluster Manager (VCM) - уровень интерфейсов управления файлом хранилища фреймов; Virtual Frame Manager (VFM) - уровень интерфейсов кэширования фреймов.
Операционная система представляет собой программу, выполняющую распределение ресурсов вычислительной системы между различными процессами. Уровень операционной системы адаптирует функции, выполняемые операционной системой, под требования остальных уровней реализации. В уровне операционной системы реализованы такие функции, как управление файлами, памятью, вводом-выводом и потоками (нитями) выполнения программы,
Уровень SRM обеспечивает адаптацию функций API операционной системы к нуждам виртуальной машины, реализующей семантическую нейронную сеть.
Уровень VMM обеспечивает управление памятью. Все блоки памяти располагаются в списке наиболее часто используемых блоков памяти. При нехватке ресурсов в системе этот список просматривается на предмет неимения часто используемых блоков. Если для размещенного блока памяти определена CALLBACK функция сборщика мусора, данный блок может быть разрушен подсистемой управления памятью. В этом случае для данного блока предварительно вызывается CALLBACK функция сборщика мусора с указанием блока памяти и причины вызова. Этот механизм используется для освобождения нейронов, которые наименее часто используются системой. Перед разрушением такого нейрона CALLBACK функция сборщика мусора сохраняет данные тела нейрона в хранилище нейронов (VCM).
Уровень VCM обеспечивает функционирование функций API файла - хранилища фреймов. Хранилище данных представляет собой структуру долговременного хранения данных, в которой содержатся данные, описывающие состояние нейронов. На уровне операционной системы хранилище данных представляет собой обычный файл. Структура хранилища, организована таким образом, чтобы состояние нейронов сохранялось целостным независимо от того, загружены или не загружены в память машины копии данных нейронов. Это достигается путем исключения из хранилища всех контекстно-зависимых данных, таких как файловые указатели и указатели на блоки памяти. При создании нового нейрона, в хранилище нейронов производится поиск какого либо свободного кластера. Адрес этого
кластера возвращается в качестве уникального идентификатора нейрона. Если нейрон в процессе своей жизни увеличивает свои размеры и выходит за пределы кластера, уровень управления хранилищем находит еще один свободный кластер и добавляет этот кластер в конец списка кластеров, используемых нейроном. Этим обеспечивается возможность хранить нейроны любого необходимого размера (в данной реализации ограничение на размер одного нейрона составляет до 231 байт - ограничение на размер целого со знаком, размещаемого в одном регистре процессора х86).
Физически нейрон реализуется в хранилище данных как поток данных (Data Stream). Благодаря этому каждый нейрон можно рассматривать как некоторый файл. В результате работа с нейроном ведется посредством функций работы с файлами, такими как чтение блока данных, запись блока данных, перемещение файлового указателя.
Внутренняя структура нейрона представлена на рис. 1.
Каждая секция нейрона может рассматриваться как поток данных (или как файл, отображенный в память) и интерпретироваться другими уровнями любым способом.
Идентификация, поиск, управление и обработка нейронов в хранилище обеспечивается с помощью идентификаторов нейронов.
Уровень VFM обеспечивает функционирование функций API кэширования фреймов. Тела нейронов на этом уровне представляют собой фреймы, находящиеся в хранилище. Уровень VFM загружает данные нейрона из хранилища в оперативную память системы. При необходимости освободить блок памяти некоторого нейрона подсистема управления памятью обращается через CALLBACK функцию к уровню кэширования. Уровень кэширования сохраняет данные тела нейрона в хранилище и освобождает блок памяти для использования в других целях. Таким образом, в виртуальной машине реализуется вытесняющий алгоритм кэширования нейронов.
Рисунок 1 — Внутренняя структура нейрона:
1 - данные тела нейрона; 2 - идентификатор нейрона в хранилище; 3 - данные тела секции; 4 - идентификатор типа секции; 5 - данные других уровней, расположенные в теле секции
3 ПРЕДСТАВЛЕНИЕ УРОВНЯ
ИНТЕРФЕЙСОВ ОПЕРАЦИОННОЙ
СИСТЕМЫ
Для реализации SRM-уровня введем понятие «поток». Здесь поток - это некоторая последовательность байт, расположенных в некотором порядке. Потоки могут быть представлены как потоки данных в файле, памяти и т. д. Для реализации потоков в проекте был создан класс CSystemStream, являющийся файлом, размещенным в файловой системе. Данный класс должен содержать методы, поддерживающие операции чтения данных из потока и записи данных в поток (методы CSystemStream__Obtain и CSystemStream__Update соответственно).
В качестве входных параметров эти методы принимают следующие данные:
- объект менеджера потоков типа;
- дескриптор открытого потока, которым ведется работа;
- позиция с которой необходимо считать или записать данные;
- размер записываемых/читаемых данных;
- выходной параметр - количество реально обработанных данных.
Для осуществления чтения и записи данных в файл необходимо создать этот файл в системе, что выполняется посредством функции CSystemStream__Extern.
Указанная функция в качестве параметров принимает атрибуты создаваемого файла, его имя в формате UNICODE и описатель потока, с которым ведется работа.
Для закрытия файла используем метод CSystemStream_Forget.
Кроме того, класс CSystemStream также предполагает наличие методов CSystemStream_Length и CSystemStream_Resize, предназначенных для определения и изменения длины потока соответственно.
Чтобы производить работу с потоком, необходимо хранить дескриптор этого потока и текущую позицию в потоке. При работе с потоком необходимо каждый раз корректировать текущую позицию. Это вполне возможно делать при каждой необходимости работы с потоком, однако это не удобно и громоздко. Для облегчения работы со потоком создается специальный объект CStreamReaderWriter.
Этот объект должен выполнять следующее:
- хранить в себе указатель на Stream с которым работает объект CStreamReaderWriter в переменной -члене класса Server;
- хранить в себе дескриптор открытого потока в переменной - члене класса Handle;
- хранить в себе текущую позицию Offset в потоке, благодаря чему отпадает необходимость хранить и корректировать эту позицию при каждом обращении к потоку;
Основными методами данного класса являются CStreamReaderWriter Obtain и CStreamReaderWri-
ter__Update, позволяющие считывать данные из текущей позиции в потоке и, соответственно производить запись в поток. Отличие данных методов от аналогичных функций класса CSystemStream состоит в том, что функции-члены класса CStreamReaderWriter не получает в качестве входных данных Handle и Offset, так как указанные параметры уже хранятся в объекте класса.
Получать и устанавливать текущую позицию в потоке позволяют методы CStreamReaderWriter__GetPosi-
tion и CStreamReaderWriter__SetPosition. Параметр
Offset данных функций представляет собой указатель, через который возвращается либо устанавливается текущая позиция. Возвращаемое/устанавливаемое значение текущей позиции является относительным. Параметр Origin задает метод относительной адресации этого значения. Он может принимать следующие значения:
#define VNPI_IO_ORIGIN_BEGIN 1 #define VNPI_IO_ORIGIN_CURRENT 2 #define VNPI_IO_ORIGIN_END 3 В случае VNPI_IO_ORIGIN_BEGIN значение текущей позиции возвращается / устанавливается относительно начала потока.
В случае VNPI_IO_ORIGIN_END при получении текущей позиции ее значение возвращается так: position = offset - stream_length. Замечание: в данном случае возвращаемое значение меньше либо равно 0. При установлении текущей позиции ее значение устанавливается относительно конца потока offset = = stream_length + position.
В случае VNPI_IO_ORIGIN_CURRENT при установлении текущей позиции ее значение устанавливается относительно текущей позиции offset = offset + position.
При получении позиции всегда возвращается 0, если значение параметра Origin равно VNPI_IO_ORI-GIN_CURRENT.
Класс CStreamReaderWriter также содержит методы CStreamReaderWriter__SetServer и CStreamReaderWriter__GetServer, CStreamReaderWriter__GetHandle и
CStreamReaderWriter__SetHandle. Эти функции просто устанавливают или возвращают соответствующие значения.
Инициализация объекта CStreamReaderWriter производится через функцию конструктора CStreamReaderWriter_ctor. При вызове конструктора в него передаются следующие параметры:
VNPIOBJECT Server - указатель на поток, с которым работает CStreamReaderWriter;
VNPIHANDLE Handle - дескриптор потока, с которым работает CStreamReaderWriter;
VNPIOFFSET Offset - текущая позиция чтения-записи в файле.
Конструктор инициализирует соответствующие члены передаваемыми параметрами.
Как было отмечено выше, поток может быть представлен не только как поток данных в файле, но и как поток данных в памяти. Для реализации потока в памяти создан специальный класс CSystemMemory. Данный класс содержит методы CSystemMemory_Obtain
и CSystemMemory__Update, аналогичные методам
CSystemStream__Obtain и CSystemStream__Update
класса CSystemStream. Для выделения блока памяти необходимого размера из кучи используется функция CSystemMemory__Create, в качестве параметра которой задается длина блока выделяемой памяти. Чтобы освободить выделенную память, используется функция CSystemMemory__Remove. Метод CSystemMemory__ReAlloc предназначен для того, чтобы изменить
размер уже созданного блока памяти. Класс CSystemMemory также содержит метод CSystemMemory__Length, позволяющий получить размер выделенной памяти в куче.
В ряде случаев существует необходимость вывода потока данных на дамповый терминал либо получения данных с клавиатуры. Для взаимодействия с консолью применяется класс
CSystemStdIO, содержащий всего два метода -
CSystemStdIO__Obtain, получающий ввод с потока
stdin и CSystemStdIO__Update - производящий вывод
в поток stdout.
4 РЕАЛИЗАЦИЯ УРОВНЯ УПРАВЛЕНИЯ ПАМЯТЬЮ
VMM - уровень виртуальной машины VNPI представлен посредством класса VMemoryManager, который работает с блоками памяти через класс CSystem-Memory, представляя собой некоторый уровень абстракции системной памяти. Внутренняя реализация представлена в виде вектора, каждый элемент которого содержит ссылку на следующий и предыдущий элементы. Программно данный вектор отображается как структура struct _s_vsrm_memory, содержащая следующие члены:
Handle - дескриптор объекта; Access - модификатор доступа типа VNPIACCESS; поле Data типа VNPIVOID __VNPI_PTR, содержащее массив данных в памяти;
LockCount типа VNPIOFFSET - количество вызванных операций Attach без Detach;
PrevEntry - указатель на предыдущую структуру _s_vsrm_memory_entry типа VSRM_MEMO-
RY_ENTRY__VNPI_PTR;
NextEntry - указатель на следующую структуру _s_vsrm_memory_entry типа VSRM_MEMO-RY_ENTRY __VNPI_PTR.
Сам класс VMemoryManager имеет следующие данные-члены:
root - объект класса _root_GenericObject;
SystemMemory - ссылка на глобальный объект потока в памяти типа VNPIOBJECT;
MemoryCounter - количество выделенной памяти данных;
HandleCounter - количество выделенных блоков VSRM_MEMORY_ENTRY типа VNPINUMBER;
MemoryLimit - максимальный размер выделяемой памяти данных;
MaxCounter - максимальное количество объектов структуры VSRM_MEMORY_ENTRY;
VSRM_MEMORY_ENTRY _VNPI_PTR FirstEntry -
указатель на первый блок из выделенных VSRM_ME-MORY_ENTRY;
VSRM_MEMORY_ENTRY__VNPI_PTR Las-
tEntry - указатель на последний блок из выделенных VSRM_MEMORY_ENTRY;
VSRM_MEMORY_ENTRY__VNPI_PTR Base-Entry - указатель на блок, являющийся первым реально (может отличаться от переменной FirstEntry);
VSRM_MEMORY_ENTRY__VNPI_PTR Empty-Entry - указатель на последний удаленный блок, в котором будет размещаться ссылка на следующую выделяемую память;
HandleCapacity типа VNPINUMBER - текущий размер блока, на который указывает BaseEntry. Данная переменная соответствует количеству структур VSRM_MEMORY_ENTRY в блоке.
Член класса VMemoryManager HandleCounter фактически содержит номер первого действительно свободного блока VSRM_MEMORY_ENTRY в векторе. А HandleCapacity задает размер этого вектора в этих блоках. Когда не останется ранее освобожденных блоков EmptyEntry и HandleCapacity = HandleCounter, то нам будет нужно нарастить следующий блок.
VMemoryManager_ctor - конструктор класса VMe-
moryManager. Конструктор используется для инициализации начальных значений. Он создает блок памяти, в котором резервируется место для начального ко-личества (задано переменной HandleCapacity, например 32 штуки) VSRM_MEMORY_ENTRY. После инициализации в данном блоке нет используемых структур VSRM_MEMO-RY_ENTRY. По мере размещения блоков в памяти с использованием VMemoryManager__Create в выделенном
блоке размещаются соответствующие блоки VSRM_ME-MORY_ENTRY.
В методах VMemoryManager__Create и VMemo-
ryManager__Resize реализуется проверка на отсутствие свободной памяти. В случае превышения допустимых значений параметров MemoryLimit или Handle-Limit запускается сборка мусора до устранения этого нарушения. Метод VMemoryManager__Resize предназначен для изменения размеров блока памяти без очистки данных. Подразумевается, что при увеличении размера блока над данными не происходит никаких из-
менений, а при уменьшении отсекается «лишняя» порция данных.
Метод класса VMemoryManager__Create отвечает за создание блока памяти. В функцию передается длина блока и дескриптор данного блока памяти. Удаление блока осуществляется посредством функции - члена VMemoryManager__Remove. При этом происходит изменение указателей соседних структур VSRM_MEMO-RY_ENTRY на предыдущий и последующий объекты структуры VSRM_MEMORY_ENTRY. Что касается удаляемого объекта, - то он хранится в качестве ссылки параметра EmptyEntry менеджера памяти.
Кроме того, для чтения и обновление блока данных
используются методы VMemoryManager__Obtain и
VMemoryManager__Update. В качестве параметров
данных функций задаются: длина считываемых и записываемых в память данных; буфер, из которого происходит считывание либо выполняется запись данных; количество реально скопированных данных.
Следует отметить, что вызов каждой из вышеперечисленных функций производится упорядочение списка VSRM_MEMORY_ENTRY (изменяются значения полей PrevEntry и NextEntry). Также в процессе своей работы VMemoryManager собирает статистику Memo-ryCounter и HandleCounter, что используется для контроля наличия свободной памяти.
5 РЕАЛИЗАЦИЯ УРОВНЯ VCM
Экспертная система может насчитывать миллиарды объектов. Даже если объем памяти, занимаемый одним объектом, невелик, емкости ОЗУ для хранения всех объектов не достаточно. Для преодоления указанного неудобства создается список наиболее часто используемых нейронов. За создание и хранение данного списка в памяти отвечает уровень VMM. В VMM cуществуют ограничения на количество присутствующих в списке объектов (Handle limit) и объем используемой памяти (Memory limit). Нейроны, не вошедшие в список, хранятся на жестком диске.
Для эффективного функционирования уровня VMM необходимо создание хранилища данных, в которое будет сбрасываться и считываться информация. Для этой цели был создан VCM - кластерный менеджер (хранилище потоков в файле).
VCM работает на основе файла. Одна база VCM представляет собой один файл в операционной системе. Данный файл содержит заголовок (header), в котором обозначен тип файла, его параметры, количество кластеров, номер первого свободного кластера.
Структура одного файла VCM представлена следующим образом: файл делится на блоки, содержащие m+1 кластеров по n байт. Каждый первый кластер блока поделен на m слотов, причем имеется взаимоодноз-
начное соответствие между слотами и кластерами блока (рис. 2).
Пусть у нас имеются блоки, содержащие 4 слота по 4 байта. Один кластер имеет размер 16 байт.
Пусть 7 - номер первого свободного кластера (рис. 3). В 7-й кластер записываются первые 16 байт блока данных. В слоте, соответствующем 7-му кластеру, хранится номер следующего свободного кластера, в который помещается следующие 16 байт блока данных. Следующий
Рисунок 2 — Внутренняя организация хранилища потоков
0
1 2
3
4
5
6 7 3
9
10 11
Header
> 9 V
/ 3 4
0
1
/
/
Рисунок 3 — Пример размещения данных в хранилище
свободный кластер имеет идентификатор 3. Слот, соответствующий номеру 3 содержит значение 9, Э и это будет номером кластера, в который будет помещена следующая порция данных. В том случае, если слот содержит значение 0 (не имеется свободных кластеров), в конец файла добавляется еще один блок m*n.
Для обеспечения функционирования хранилища данных используется ряд следующих методов.
Метод Create позволяет создать цепочку кластеров указанной длины. Данная функция находит свободный блок, размещает блоки на величину указанной длины. Возвращаемым значением функции является номер первого свободного кластера. Методы Obtain и Update позволяют считывать и записывать данные в кластер соответственно. Функция Length возвращает длину хранилища (общий размер блоков в цепочке). Метод Resize позволяет изменить размер (длину) хранилища данных. Все вышеперечисленные методы реализуются с помощью набора API функций.
6 РЕАЛИЗАЦИЯ УРОВНЯ VFM
Уровень VFM позволяет кэшировать объекты в памяти. Каждый объект имеет свой идентификатор (Handle), что позволяет осуществлять к нему доступ.
Базовыми методами, позволяющими реализовать кэширование нейронов в памяти, являются Attach и Detach. Основными параметрами, принимаемыми данными функциями являются:
_VFM - указатель на блок VFM; Handle - номер объекта, на который указывает последний параметр, принимаемый функцией;
Access - атрибут, определяющий, для чтения или для записи устанавливается доступ к требуемому параметру;
pObj - указатель на объект внутри блока VFM. Рассмотрим следующий пример. Пусть имеется указатель на объект (1) p1. Необходимо получить указатель p3 на объект (3). Это достигается путем использования функций:
p1-> Attach (p1, (2), VPDATE, &p2); p2-> Attach (p2, (3), VPDATE, &p3); Пусть имеется указатель p1 на объект, содержащий 4 потока по 10 байт каждый. Для копирования в буфер содержимого одного из потоков используется функция Obtain (pObj, Handle, Length, &Buffer), где pObj - указатель на объект внутри блока VFM; Handle - номер потока внутри объекта; Length - размер копируемого потока; Buffer - буфер, в который осуществляется копирование данных.
В данном примере вызов функции чтения потока в буфер выглядит так:
Obtain (p1, (4), 10, &Buffer).
лых числа, определяющих идентификаторы некоторых объектов. Иначе говоря, поток (4) содержит идентификаторы других нейронов. Так реализуется система связей между нейронами в базе.
7 ПРИМЕНЕНИЕ ЭС, РАЗРАБОТАННОЙ НА
БАЗЕ НС, В ЦЕЛЯХ ДИАГНОСТИКИ
КОМПЬЮТЕРНЫХ СЕТЕЙ
ЭС, построенная на основе разработанной нейронной сети, может быть использована в целях диагностирования средства диагностирования вычислительных сетей. Экспертные системы для решения задач диагностирования вычислительных сетей аккумулируют человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние.
Рассматриваемая система распознает широкий ряд проблем, которые могут указать на наличие скрытого дефекта или узкого места в компоненте сети, выдает сообщения об их появлении, предоставляет рекомендации по их исправлению.
В табл. 1 приведена сравнительная характеристика наиболее популярных экспертных систем диагностирования сетей и разработанной на базе УКР1 ЭС. Как правило, ЭС диагностирования сетей являются встроенными в анализаторы протоколов либо поставляются в виде отдельных подключаемых модулей.
Таблица 1 — Сравнительная характеристика экспертных систем диагностирования сетей
^^^^^^^ Эксп. система Характеристики ^^^^^^^ Observer Expert Extention Prisma Lite DSS Expert Analysis Agilent Network Analyzer OptiView Protocol Expert ЭС на базе VNPI
Экспертный анализ в реальном режиме времени + + + + + +
Наличие задач-экспертов для стеков протоколов + - + - + -
Анализ временных интервалов + - + + + +
Режим моделирования характеристик сети + + - - - -
Функция оповещения + + + + + +
Интерпретация диагноза + + + + + +
Рекомендации по устранению проблемы - - + - - +
Функция планирования эксперимента - - - - - -
Удаленный анализ + + + - + +
Иерархия уровня УЕМ организована следующим образом. Существует один корневой блок без номера, на который имеется указатель: блок УЕМ, внутри -подблоки нейроны, на концах которых - потоки.
Пусть наша многоуровневая система насчитывает значительное количество нейронов (блоков). Задача состоит в необходимости получения указателя на конкретный объект. Это может быть достигнуто через уникальный идентификатор нейрона.
Пусть имеется объект с идентификатором 50. Представленный на рис. 4 нейрон содержит секции данных, имеющие номера (1), (2), (3)... По номеру некоторой секции можно получить на нее указатель. Тело секции представляет собой поток длиной 16 байт, состоящий из 4-х блоков по 4 байта. Таким образом, в каждую секцию может быть помещено четыре 32-битовых це-
Рисунок 4 — Организация связей между объектами через идентификатор нейрона
ВЫВОДЫ
В данной работе была представлена архитектура ядра виртуальной машины нейронной сети, проектируемой с целью построения ЭС на базе представленной модели. Ядро реализуется в парадигме компонентного программирования, этим обеспечивается возможность динамически изменять архитектуру ядра без перекомпиляции отдельных компонентов. Представленная виртуальная машина эмулирует параллельное выполнение нейронов в сети. Были описаны уровни VNPI, состоящие из набора классов и соответствующих методов.
Уровень интерфейсов операционной системы обеспечивает адаптацию функций API операционной системы к характеристикам виртуальной машины, реализующей семантическую нейронную сеть. На данном уровне рассматривается работа с потоками данных в файле, что отражает класс CSystemStream, либо памяти, что реализуется посредством класса CSystemMemory. Для упрощения работы с потоком создается специальный объект CStreamReaderWriter.
Уровень управления памятью и сборщик мусора обеспечивает распределение памяти. Реализация данного уровня достигается путем использования объектов VMemoryManager, представляющих собой связные списки, содержащие ссылку на следующий и предыдущий элементы.
Уровень интерфейсов управления файлом хранилища фреймов обеспечивает функционирование функций API файла - хранилища фреймов. Уровень интерфейсов кэширования фреймов обеспечивает функционирование функций API кэширования фреймов.
На основе представленной НС была реализована ЭС, используемая для диагностирования компьютер-
ных сетей. Недостатками данной ЭС является отсутствие режима моделирования характеристик сети и отсутствие задач-экспертов для стеков протоколов. К числу преимуществ данной ЭС можно отнести эффективность управления ресурсами ее виртуальной машины и эффективность организации связей между объектами.
ПЕРЕЧЕНЬ ССЫЛОК
1. Кривуля Г. Ф., Бабич А. В., Липчанский А. И., Шкиль А. С. Применение экспертных систем реального времени для диагностики компьютерных систем. // ¡нформацшно-керуюч! системи на зал1зничному транспорт!. - 2004. -№ 1. - С. 56-62.
2. Дударь 3. В., Шуклин Д. Е. Реализация нейронов в семантических нейронных сетях // Радиоэлектроника и информатика. - 2000. - № 4. - С. 89-96.
3. Шуклин Д. Е. Принципы построения компонентной архитектуры ядра виртуальной машины эмулирующей семантическую нейронную сеть // 8-й международный молодежный форум «Радиоэлектроника и молодежь в XXI веке». Ч. 2.: Сб. материалов форума. - Харьков: ХНУРЭ. 2004. - С. 101.
Надшшла 22.02.06
У po6omi розглядаеться можлив1сть використання ек-cnepmno'i системи на 6a3i нейронно'( Mepexi у щлях дiаг-ностики кoмn'юmеpнoi MepeMi. Пропонуеться програмна побудова нeйpoннoi MepeMi у виглядi бaгamopiвнeвoi системи. Кожен piвeнь вкaзaнoi системи представляеться cукуnнicmю клaciв i мemoдiв, що виконують перетво-рення даних.
The application possibility of the expert system, built on the basis of neuron net, is considered in the purposes of computer net diagnostics. The program construction of the neuron net in the form of multilevel system is proposed. Each level of the mentioned system is represented by the set of classes and data transformation fulfilling methods.
YAK 681.3.06; 681.3.07
P. К. Кудерметов, А. М. Щербаков, М. Ю. Юрич
СТРУКТУРОЙ СИНТЕЗ 0ПЕРАЦ1ЙНИХ М0ДУЛ1В М0ДУЛЯРН01 АРИФМЕТИКИ НЕЙР0ННИХ МЕРЕЖ ПАРАЛЕЛЬНИХ ОБЧИСЛЕНЬ
Розглянута можливкть розширення сфери застосування нейронних мереж для паралельно'1 обробки даних у моду-лярнш cиcmемi залишкових клаciв. Наведенш результати структурного cинmезу операцшного модуля дiлення чиcел модулярно'1 арифметики.
ВСТУП
Проектування параметричних шформацшних метасистем з управлшня швидюсними процесами не обходиться без вимоги контролю дшсних сташв та прогно-зування подальшо! поведшки об'екив у режим1 реального часу.
Здшснення одночасного, контролю, наприклад, ильки координат траекторИ руху об'екту та розрахун-
© Кудерметов Р. К., Щербаков А. М., Юрич М. Ю., 2006 102 ISSN 1607-3274 «Радтелектрошка. 1нформатика. Управлшня» № 1, 2006
