автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.07, диссертация на тему:Повышение уровня сервиса для разработчиков распределенных систем управления в сетях с протоколами ТСР/IP

ГОСУДАРСТВЕННЫЙ КОМИТЕТ РОССИЙСКОЙ ФЕДЕРАЦИИ ПО ВЫСШЕМУ ОБРАЗОВАНИЮ

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ "СТАНКИН"

, , ; • На правах рукописи

i ri iiL.il U;J'J

ТУРЧЕНКО ВЛАДИСЛАВ НИКОЛАЕВИЧ

УДК 681.324.068:681.51.003.13 (043.3)

ПОВЫШЕНИЕ УРОВНЯ СЕРВИСА ДЛЯ РАЗРАБОТЧИКОВ РАСПРЕДЕЛЕННЫХ СИСТЕМ УПРАВЛЕНИЯ В СЕТЯХ С ПРОТОКОЛАМИ TCP/IP.

Специальность 05.13.07 — Автоматизация технологических процессов и производств.

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

Москва 1996

Работа выполнена на кафедре "Компьютерные системы управления" Московского Технологического Университета "СТАНКИН".

Научный руководитель: — доктор технических наук,

профессор Сосонкин В.Л.

Официальные оппоненты: — доктор технических наук,

профессор Аршанский М.М.; — кандидат технических наук, доцент Колчин А.Ф.

Коллективный оппонент: — ПНИИММ

Ведущая организация: — Пензенский Государственный

Технический Университет

Защита состоится# декабря 1996 г. в_часов на заседании

специализированного совета К 063.42.04 Московского Государственного Технологического Университета "СТАНКИН" по адресу:

101472, Москва, Вадковский пер., д.За.

С диссертацией можно ознакомиться в библиотеке университета "СТАНКИН" .

Автореферат разослан 20 октября 1996 г.

Ученый секретарь специализированного совета К 063.42.04, кандидат технических наук,

доцент Горшков А.Ф.

Общая характеристика работы

Актуальность темы

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

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

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

Для достижения совместимости разработчики распределенных систем используют частные сетевые системы одного производителя

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

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

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

С другой стороны, существуют и другие концепции развития коммуникационных систем; например, набор протоколов Управленр Перспективных Исследований Министерства Обороны США, известный как набор протоколов TCP/IP. Благодаря бурному развитию глобальной компьютерной сети Internet в последние годы протоколы TCP/IP получили чрезвычайно широкое распространени Именно поэтому возникает объективная потребность в построении распределенных систем управления на основе сетей с такими протоколами.

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

Цель и задачи исследования

Целью диссертационной работы является исследование и разработка сервиса построения распределенных систем управления на основе сетей с протоколами TCP/IP.

Для достижения поставленной цели необходимо решить ряд теоретических и практических проблем:

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

2. Выполнить анализ существующего сервиса для построения распределенных систем управления на основе эталонной модели ВОС/МОС;

3. Рассмотреть возможности набора протоколов TCP/IP для построения распределенных систем управления и сравнить их с моделью сервиса ВОС/МОС;

4. Разработать методы построения сервиса ВОС/МОС над TCP/IP;

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

6. Осуществить программную реализацию синтезированной модели.

Методы исследования

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

Научная новизна

К новым результатам, полученным в процессе исследований, можно отнести следующие:

1. Установление точного соответствия стандартных сетевых программных средств модели Взаимодействия Открытых

Систем МОС и набора протоколов TCP/IP, используемого в глобальной компьютерной сети Internet.

2. Синтез в рамках философии ВОС моделей прикладного, сессионного и представительского уровней, реализующих стандартные услуги для таких сетевых программно — аппаратных средств, у которых эти уровни отсутствуют.

3. Разработка новых групп прикладного сервиса построения распределенных систем управления — прогнозирования изменения передаваемых по сети данных и диспетчеризация циркулирующих в сети сообщений.

Практическая ценность

Для операционных систем UNIX и Windows разработано программное обеспечение, реализующее дополнительно выстроенные уровни сервиса. На верхнем уровне разработанной модели сервиса созданы специфические группы прикладных услуг, служащие для уменьшения сетевого трафика и диспетчеризации сообщений. Эта разработка позволяет создавать и развивать эффективные распределенные многомашинные системы управления на основе протоколов TCP/IP или других сетевых систем, отличающихся от эталонной модели ВОС.

Реализация и апробация работы

Материалы диссертационной работы в виде методик и программного обеспечения использованы при построении модели взаимодействия объектов глобальной компьютерной сети Internet в проектах акционерного общества "Аниматек" (г. Москва).

Публикации

По теме диссертации опубликовано 3 печатных работы.

Структура и объем работы

Диссертация состоит из введения, четырех глав с выводами, общих выводов, списка литературы из 85 наименований. Работа содержит 135 страниц машинописного текста с 45 рисунками и 4 таблицами.

Содержание работы

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

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

Указанные проблемы определяют актуальность разработки сервиса, соответствующего эталонной модели ВОС над протоколами TCP/IP, а также специфического сервиса построения распределенных систем управления производством на прикладном уровне разрабатываемой модели.

В первой главе выполнен анализ мирового опыта построения распределенных систем управления производством.

При построении распределенных систем управления важнейшее значение имеют вопросы стандартизации программных и аппаратных средств обработки данных, систем коммуникаций, связывающих все звенья системы. В силу высокой важности интеграции машиностроительного оборудования были сформированы два долгосрочных проекта, цель которых состояла в разработке стандартов для создания открытых коммуникационных систем промышленных предприятий. Начало было положено в 1982 году фирмой General Motors (GM) (США), объявившей о разработке серии стандартов под названием "Протокол автоматизации производства" — MAP. Позднее к этому проекту присоединилась фирма Boeing (США),

занимавшаяся созданием серии стандартов "Протокол технического административного учреждения" — ТОР для локальных вычислительных сетей конструкторских бюро и учреждений.

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

Набор конструктивных блоков проекта MAP/TOP представлен н Рис. 1.

Концепция конструктивных блоков в проекте MAP/TOP основана i международном опыте автоматизации предприятий и обеспечивает богатый сервис построения распределенных систем управления этиг предприятиями. Важнейшим принципом является широкое использование эталонной модели взаимодействия открытых систем (ВОС) Международной организации по стандартизации (МОС) и разработанных в рамках модели протоколов и интерфейсов. Развиваемая в МОС архитектура открытых систем (АОС) стала концептуальной основой технических решений по созданию распределенных систем управления производством.

Физическая среда передачи данных

Рис. 1 Набор конструктивных блоков проекта MAP/TOP.

Эталонная модель ВОС базируется на четырех понятиях: открытая система, прикладные объекты, соединения, физическая среда для ВОС. Открытая система может быть представлена в виде иерархических подсистем. Подсистемы, выполняющие однообразные наборы функций взаимосвязи, образуют уровень. Для локализации функций используется понятие объекта. Таким образом, подсистема N —уровня (N — подсистема) состоит из одного или нескольких N — объектов.

Каждый N —уровень, за исключением верхнего, обеспечивает N — услуги для (N + 1)—объектов (N+1)—уровня. Услуги N — уровня представляются (N+1)— уровню путем выполнения N —функций

внутри N —уровня, а также за счет использования услуг, получаемых от (N—1)—уровня. Взаимодействие между N —объектами осуществляется под управлением одного или нескольких N — протоколов.

Объекты смежных уровней взаимодействуют друг с другом через общую границу, содержащую сервисные точки доступа (СТД). Через N —СТД происходит предоставление сервиса N —уровнем и потребление сервиса (N +1) —уровнем. Местоположение N —СТД определяется N —адресом.

Допустимые последовательности сообщений пользователя являются внешним (сервисным) описанием протокольного уровня.

Сервис уровня определяется через элементы абстрактной модели взаимодействия пользователя и поставщика. Абстрактная модель включает следующие понятия: пользователи N — сервиса, поставщик N — сервиса и сервисные примитивы. К примитивам относятся первичные неделимые элементы описания сервиса, в числе которых примитивы запроса (request), индикации (indication), ответа (response) и подтверждения (confirmation).

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

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

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

Система А

Система В

Уровень 7

Уровень 6

Уровень 5

Уровень 4

Уровень 3

Уровень 2

Уровень 1

Прикладной

интерфейс

Представительс кий

интерфейс

Сессионный

интерфейс

Транспортны! 1

интерфейс

Сетевой

интерфейс

Канальный

интерфейс

Физический

протокол

протокол

ггротоко \

протокол

протокол

протокол

протокол

А

Прикладной

интерфейс

Представительс кий

интерфейс

Сессионный

интерфейс

Транспортны» I

интерфейс

Сетевой

интерфейс

Канальный

интерфейс

Физический

Рис. 2 Структура уровней ВОС

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

В данной главе рассматривается взаимодействие уровней ВОС, начиная с транспортного и выше.

Для выполнения специфических задач построения распределенных систем управления на прикладном уровне ВОС построены специальные группы сервиса.

1. Служба передачи, доступа и управления файлами (РТАМ), которая является одной из важнейших составных частей

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

2. Сервис обеспечения неделимости распределенных действий, который поддерживает одновременное функционирование прикладных распределенных систем.

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

4. Сервис пересылки и управления заданиями (JTM), который предоставляет возможность удаленного запуска заданий, контроль их выполнения, получение результатов выполнения заданий. Эта группа специфических прикладных услуг является особо важной при распределенной обработке информации в вычислительных сетях.

Таким образом, анализ опыта построения распределенных систем управления показал, что сегодня существует общепринятый стандарт построения распределенных многомашинных систем управления, известный как проект MAP/TOP, построенный на модели взаимодействия открытых систем (ВОС). Конструктивные блоки MAP/TOP, опираясь на прикладной уровень ВОС, предоставляют богатый сервис разработчикам распределенных систем управления и открыты для дальнейшего расширения.

На практике протоколы ВОС получили распространение только на крупных предприятиях. В мелких учреждениях и предприятиях они не используются из — за своей громоздкости, а также в силу исторических причин. К этим причинам можно отнести то, что протоколы ВОС находились в стадии разработки, а более простые протоколы TCP/IP уже стали применять в Internet.

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

задач.

Во второй главе проведен анализ сетевых программных средств TCP/IP в операционных системах UNIX и Windows, и поставлены задачи исследования.

Протоколы TCP/IP не вполне соответствуют семиуровневой модели ВОС, но широко применяются во всем мире для объединения компьютеров в сеть Internet. Internet состоит из множества сетей различной физической природы, от локальных сетей типа Ethernet и Token Ring до глобальных сетей типа NSFNET. Известно множество реализаций набора протоколов TCP/IP различных производителей.

TCP/IP — многоуровневый набор протоколов. Традиционно описываемая иерархия TCP/IP представлена на Рис. 3.

Концептуальный уровень Данные, передаваемые между уровнями

Прикладной уровень

Прикладные сообщения

Транспортный уровень

Межсетевой уровень

Транспортные сообщения IP-пакеты

Сетевой уровень

_Кадры среды передачи данных

Физическая среда

Рис. 3 Иерархия управления TCP/IP. Уровни TCP/IP имеют следующее назначение:

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

♦ Транспортный уровень организует обмен сообщениями между различными прикладными процессами через взаимодействие "точка—точка", регулирует поток информации. На этом уровн( работают протоколы TCP и UDP.

♦ Межсетевой уровень управляет обменом сообщениями между машинами. Здесь работает протокол IP: принимает запрос на пересылку сообщения с транспортного уровня, упаковывает сообщение в IP — пакет, заполняет его заголовок, использует таблицу маршрутизации, передает пакет через подходящий сетевой интерфейс, а также посылает и обрабатывает ICMP — пакеты с сообщениями об ошибках и управляющей информацией.

♦ Сетевой уровень предназначен для приема от межсетевого уровня IP — пакетов и их передачи через физическую сеть.

К методам сетевого программирования TCP/IP, доступным разработчикам, относятся:

♦ библиотека транспортного уровня TLI (Transport Layer Interface соответствующая на транспортном уровне протоколам ВОС;

♦ библиотеки сокетов UNIX и Windows;

♦ грс — программирование (вызов удаленных процедур).

В результате исследования сделаны следующие выводы:

♦ пользователям набора протоколов TCP/IP доступны аналоги транспортного, сетевого и части прикладного уровней модели ВОС;

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

♦ набор протоколов TCP/IP является перспективным средством, на базе которого можно организовать взаимодействие в

распределенной многомашинной системе управления производством;

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

♦ сервис достраиваемого прикладного уровня должен обеспечивать совместимость со стандартами протоколов автоматизации MAP и ТОР.

Для повышения уровня сервиса в распределенных системах управления на основе сетей с протоколами TCP/IP необходимо решить следующие задачи:

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

♦ определить набор услуг, который должен быть реализован в рамках достраиваемых уровней;

♦ разработать схему предоставления каждой услуги;

♦ осуществить программную реализацию синтезированной модели;

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

В третьей главе выполнено моделирование сервиса эталонной модели ВОС над транспортным уровнем TCP/IP и построение на основе сервиса некоторой экспериментальной распределенной системы управления.

Взаимодействие набора протоколов TCP/IP и вершины эталонной модели ВОС во многом зависит от выбора метода сетевого программирования. Рассмотренные ранее методы сетевого программирования различаются предоставляемым сервисом, реализацией на различных платформах, степенью соответствия

эталонной модели ВОС. В данной работе автором выбран метод программирования с использованием сокетов, позволяющий получит доступ к набору протоколов TCP/IP на транспортном уровне.

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

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

Позиции сети имеют следующее назначение:

Р1 — посылка серверу запроса на организацию представительского соединения;

Р2 — синхронное ожидание клиентом результатов установления представительского соединения;

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

Р4 — синхронное ожидание клиентом результатов согласования параметров прикладной ассоциации;

Р5 — обработка возвращенных сервером параметров прикладной ассоциации, регистрация прикладной ассоциации;

Р6 — запуск процесса сервера на прослушивание запросов на установление соединения;

Р7 — обработка поступившей индикации установления представительского соединения; установление представительского

Рис. 4 Модель развития услуги A —ASSOCIATE.

Р8 — синхронный прием параметров согласования прикладной ассоциации; в случае отказа в установлении представительского соединения — подготовка данных к поступлению новых запросов;

Р9 — обработка полученных параметров согласования прикладной ассоциации; формирование на их основе своего набора параметров и пересылка его клиенту;

Р10 — регистрация сервером прикладной ассоциации;

PI 1 — завершение клиентом процесса установления прикладной ассоциации, передача инициатору кода отказа в установлении ассоциации;

Р12 — подготовка сервером данных к поступлению запросов на установление прикладной ассоциации.

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

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

Уменьшения сетевого трафика можно достичь несколькими способами:

♦ постоянным повышением пропускной способности путем обновления аппаратуры сети, что требует немалых затрат;

♦ применением методов динамической упаковки передаваемых данных перед передачей по линиям связи и распаковки на другом конце соединения;

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

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

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

>том в очереди могут находиться любые сообщения, независимо от IX источника.

Приоритеты различных сообщений задаются при проектировании

распределенной системы управления. Эти данные должны быть доступны всем объектам системы и не могут быть динамически изменены.

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

Источниками сообщений к объекту могут быть:

► сетевой объект —партнер по системе: сообщения о состоянии объектов, команды от управляющего объекта, файлы, программы ЧПУ и так далее;

► операционная система, в которой работает объект: информация об ошибках и конфликтах в операционной системе;

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

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

При поступлении сообщения модуль—диспетчер помещает его в >чередь вслед за последним сообщением с аналогичным или большим фиоритетом. При обработке очереди сообщений модуль—диспетчер 5ерет первое сообщение с наивысшим приоритетом и помещает его в

модуль обработки сообщений данного приоритета, удаляя его тем самым из очереди. Обработка очереди сообщений завершается после того, как очередь становится пустой. Особым образом при программной реализации сервиса прикладного уровня необходимо предусмотреть методы защиты от зацикливания очереди, — когда процедура обработки сообщения помещает в очередь аналогичное сообщение (Рис. 5).

Очередь сообщений

Сообщение #1 приоритет О

Сообщение #2 приоритет 1

Сообщение #2 приоритет 1

Сообщение #2 приоритет 2

Сообщение #2 приоритет 3

Новое сообщение приоритет 1

Рис. 5 Поступление в очередь нового сообщения.

Результатами третьей главы являются следующие:

1. Создана схема обеспечения сервиса, основанная на поддержке библиотеками сокетов или интерфейса транспортного уровня TLI протоколов TCP/IP снизу и сервиса прикладного уровня эталонной модели ВОС сверху.

2. Разработаны принципы совмещения сервиса транспортного уровня TCP/IP и сессионного уровня модели ВОС.

3. Определены принципы и необходимые структуры данных для функционирования представительского и сессионного сервиса разработки РСУ.

4. Промоделированы принципы функционирования базового ядра прикладного сервиса разработки РСУ.

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

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

В четвертой главе описана программная реализация синтезированной модели сервиса построения распределенных систем

управления.

Исходя из выбора метода сетевого программирования, для программной реализации сервиса построения распределенных систем управления был выбран язык С(С + +). Этот язык является основным средством разработки прикладных программ для UNIX и Windows, и именно на нем реализован интерфейс библиотеки сокетов и транспортного уровня TLI.

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

прикладном уровне.

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

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

public :

CMessage (long code, long len) ; -CMessage ();

char *GetDataBuffer () {return data}; long GetDataLen () {return len}; long GetDataCode () {return code};

public:

/* Указатель на сообщение, управляемое более высоким уровнем */

} ;

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

CMessage *CSConnection::CheckConnection () { CMessage *m = CTConnection:: CheckConnection (); if (m) {

CMessage *mt = m->Hole; /* обработка данных, предназначенных для текущего уровня

ProcessMessage ( m->code, m->data); /* удаление заголовка текущего уровня */ m_.Hole = NULL; delete m;

m = mt; }

return m;

CMessage protected:

*Hole;

long long char

code ;

len;

*data;

}

При прохождении сообщения сверху вниз уровень инициализирует товое сообщение, помещает в поля code и data некоторые данные для

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

int CSConnection: : Send ( CMessage zhar -pur;

CMessage *sm = new CMessage (0,0);

/1 Данные code ti Ion ASSERT (sm); sm->Hole = m;

if ( CTConnection::Send ( sm)) {

fprintf ( stdout, "Ошибка посылки

транспортного сообщения!\n");

return -1;

/

return 0;

1

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

:lass DMessage: public CMessage { public:

DMessage (CMessage*);

~DMessage (); public:

/* вновь организуемые данные - адреса машины и задачи */ long mach_address;

long port;

protected:

long code;

char *data;

} ;

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

void CAppLayer::DispetchMessage (CMessage *m) { /* Пуст ли список сообщений ? */

if ( MessagesList.IsEmpty()) { /* Добавить сообщение в конец списка */

MessagesList.AddTail (m) ; }

else {

/* цикл по всем имеющимся в списке сообщениям */

for ( POSITION pos = MessagesList. GetHeadPosition ();pos;) {

if ( ! pos) {

/* добавить сообщение в конец списка, если все сообщения - с более высоким приоритетом */

MessagesList.AddTail (ш);

break; }

CMessage ""rness =

(CMessage*)MessagesList. GetNext (pos); /* добавить сообщение перед сообщением с более низким приоритетом */

if ( mess && mess->code > m->code) {

pos = MessagesList.GetPrev (pos);

MessagesList.InsertBefore(pos,m);

break;

}

}

}

} . . . . .

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

Основные выводы и результаты работы

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

2. Набор протоколов TCP/IP отличается распространенностью практически на всех компьютерных платформах, но по уровню сервиса построения распределенных систем управления соответствует лишь транспортному уровню ВОС.

3. Для построения распределенной системы управления, соответствующей рекомендациям ВОС, на базе протоколов TCP/IP необходимо достроить отсутствующие уровни иерархии — сессионный, представительский и прикладной.

4. Синтезированная модель сервиса сессионного и прикладного уровней соответствует требованиям ВОС и обеспечивает сервис построения распределенных систем управления, открытый для дальнейшего расширения.

5. Программное обеспечение, разработанное в процессе создания сервиса, позволяет повысить скорость разработки и надежность функционирования распределенных многомашинных систем управления на основе сетей с протоколами TCP/IP.

Основное содержание работы отражено в следующих публикация?

1. Турченко В.Н., Муравьев В.В.: Локальная вычислительная сеть EasyLAN // информационный листок N88 — 95, ПЦНТИ, Пензе 1995.

2. Турченко В.Н.: Разработка схемы диспетчеризации сообщенш распределенной системы управления // Пензенская Государственная Архитектурно — Строительная Академия, Пенза, 1996

3. Турченко В.Н.: Моделирование группы услуг прогнозирования изменения передаваемых данных в распределенных системах управления // Пензенская Государственная Архитектурно — Строительная Академия, Пенза, 1996

Введение.

Глава 1.Анализ мирового опыта построения распределенных систем управления производством.

1.1 Типичные компоненты распределенных систем управления.

1.2 Анализ мирового опыта создания стандартов открытых коммуникационных систем автоматизации предприятия на примере проектов MAP и ТОР.

1.2.1 Конструктивные блоки MAP/TOP.

1.3 Эталонная модель ВСЮ - основа построения открытых информационно-управляющих систем.

1.3.1 Структура уровней ВОС.

1.3.2 Принципы реализации сервиса модели ВОС.

1.3.3 Сервис транспортного уровня.

1.3.3.1 Транспортный сервис с соединением.

1.3.4 Сервис сессионного уровня.

1.3.4.1 Новые понятия, введенные в сессионном сервисе.

1.3.5 Общий прикладной сервис.

1.3.5.1 Базовое ядро общих прикладных услуг.

1.3.5.2 Специфический прикладной сервис.

1.4 Соотношение стандартов MAP, ТОР и эталонной модели ВОС.

1.5 Выводы.

Глава 2.Анализ сетевых программных средств TCP/IP в UNIX и Windows. Постановка задачи.

2.1 Введение в TCP/IP.

2.2 Общее описание набора протоколов TCP/IP.

2.2.1 Формирование дейтаграмм на уровне TCP.

2.2.2 Работа с данными на уровне UDP.

2.2.3 Работа с данными на уровне IP.

2.2.4 Прохождение дейтаграмм через уровень Ethernet. 2.3 Обзор Прикладного Уровня TCP/IP.

2.4 Обзор методов сетевого программирования TCP/IP.

2.5 Сравнение TCP/IP с Моделью Сетевой Архитектуры МОС ВОС

2.6 Постановка задачи исследования.

2.7 Выводы.

Глава 3.Моделирование сервиса эталонной модели ВОС над транспортным уровнем TCP/IP и построение на его основе экспериментальной распределенной системы управления.

3.1 Определение уровня взаимодействия набора протоколов TCP/IP и верхних уровней ВОС.

3.2 Разработка схемы сервиса моделируемых уровней.

3.3 Моделирование общего сервиса разработки распределенных систем управления.

3.4 Разработка специфического интерфейса транспортного уровня.

3.5 Разработка принципов обслуживания на сессионном и представительском уровнях.

3.6 Моделирование базового ядра прикладных услуг.

3.7 Моделирование группы услуг прогнозирования изменения передаваемых данных.

3.8 Разработка схемы диспетчеризации сообщений распределенной системы управления.

3.9 Разработка модели применения сервиса построения распределенной системы управления.

3.10 Выводы.

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

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

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

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

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

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

С другой стороны, имеются другие концепции развития коммуникационных систем. Имеется в виду, в частности, набор протоколов Управления Перспективных Исследований Министерства Обороны США, известный как набор протоколов TCP/IP. В силу исторических причин, а именно бурного развития Internet в последние годы, TCP/IP получил чрезвычайно широкое распространение в мире. Именно поэтому существует объективная потребность в построении распределенных систем управления на основе сетей с этими протоколами.

Нет сомнений в том, что архитектура ВОС более богата и сложна чем архитектура набора протоколов TCP/IP. Сервис ВОС предоставляет максимум возможностей для разработки надежных управляющих систем, так как он построен с учетом многолетнего опыта применения сетевых технологий для автоматизации промышленных предприятий. В данной работе решается задача построения сервиса для разработчиков распределенных систем управления, работающих в сетях с протоколами TCP/IP. Создаваемый сервис должен вобрать в себя богатство возможностей модели ВОС, а также простоту и открытость протоколов TCP/IP. Для этого необходимо провести анализ обеих архитектур, определить место TCP/IP в семиуровневой модели ВОС, и разработать методику построения прикладного сервиса над средствами поддержки протоколов TCP/IP.

4.5 Выводы.

1. Для программной реализации сервиса построения распределенных систем управления выбран язык С(С+ +), так как этот язык является основным средством разработки прикладных программ для UNIX и Windows и именно на нем реализован интерфейс библиотек сокетов и транспортного уровня TLI.

2. При построении сервиса разработки распределенных систем управления целесообразно использовать средства иерархического упорядочивания данных, доступных с применением языка С + +.

3. Разработана структура классов, соответствующая иерархии уровней ВОС, со схемой наследования свойств и функций от низшего класса к высшему.

4. Разработчик распределенной системы управления использует высший класс CAppLayer в качестве родителя собственного класса, являющегося по сути программой управления объектом распределенной системы.

5. Каждый класс —уровень ВОС использует условно одноуровневый с ним класс соединения, который помещает в область своих локальных данных. Наивысший по иерархии класс соединения является прикладной ассоциацией с соответствующими параметрами.

6. Возможно проведение разработки каждого класса сервиса отдельными группами работников, что ускорит процесс разработки и повысит надежность системы в целом.

7. Разработаны специализированные классы сообщений, позволяющие производить межуровневый обмен сообщениями по принципам ВОС.

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

Заключение

1. Протоколы ВОС — МОС являются первым опытом так 11 II тч называемой опережающей стандартизации . В настоящее время распределенные системы управления строятся на базе именно этих протоколов.

2. Протоколы автоматизации предприятия, известные как проект MAP/TOP, построены на использовании открытой архитектуры ВОС. В них сосредоточен мировой опыт автоматизации крупных предприятий.

3. Основной доступной разработчику частью сервиса построения РСУ является, согласно модели ВОС, прикладной уровень. Именно на построении прикладного сервиса необходимо сосредоточить основное внимание при разработке сервиса.

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

5. Необходимость построения распределенных систем управления производством на базе протоколов TCP/IP обусловлена чрезвычайно широким распространением данного набора протоколов в мире благодаря глобальной сети Internet. Данный набор протоколов, в отличие от протоколов ВОС —МОС, развивался по принципу постепенной стандартизации, то есть наиболее удачные решения в процессе практического использования признавались стандартами.

6. Сервис протоколов TCP/IP для построения распределенных систем управления логически соответствует транспортному и прикладному уровням ВОС. Данное обстоятельство затрудняет

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

7. Существующий сервис построения систем с использованием протоколов TCP/IP не соответствует идеологии ВОС, что затрудняет использование мирового опыта построения распределенных систем управления.

8. Схема иерархического наследования услуг от нижних уровней модели к верхним, примененная при разработке модели сервиса, соответствует концепции ВОС и может быть применена для разработки распределенных систем как на основе протоколов TCP/IP, так и протоколов ВОС.

9. В результате проведенного моделирования определены принципы и необходимые структуры данных для функционирования представительского и сессионного сервиса разработки РСУ.

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

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

12. Разработана схема функционирования объекта внутри распределенной системы, используещей моделируемый сервис.

13. При построении сервиса разработки распределенных систем управления используется средства иерархического упорядочивания данных, доступных с применением объектно — ориентированной технологии языка С + +.

14. В работе разработана структура классов, соответствующая иерархии уровней ВОС, со схемой наследования свойств и функций от низшего класса к высшему.

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

1. Якубайтис Э.А. Информационно — вычислительные сети. — М.: Финансы и статистика, 1984.— 232 с.

2. Якубайтис Э.А. Локальные информационно — вычислительные сети. — Рига: Зинатне, 1985.— 284 с.

3. Зайцев С.С. Транспортировка данных в сетях ЭВМ. — М.: Радио и связь, 1985.— 126 с.

4. Самойленко С.И. Сети ЭВМ. м.: Наука, 1986.- 113 с.

5. Мизин И.А., Богатырев В.А., Кулешов А.П. Сети коммутации пакетов. — М.: Радио и связь, 1986.— 408 с.

6. Прангишвили И.В., Подлазов B.C., Стецюра Г.Г. Локальные микропроцессорные вычислительные сети. — М.: Наука, 1984.— 176 с.

7. Девис Д. Вычислительные сети и сетевые протоколы: Перевод с английского. М.: Мир, 1982,— 563 с.

8. ISO/IS 7498. Information processing Systems. Open System Interconnection. Basic Reference Model.

9. ISO/IS 8509. Information processing Systems. Open System Interconnection. Basic Reference Model.lO.ISO/IS 7498/A001. Addendum to ISO 7498. Covering Connectionless. Mode Transmission.

10. ISO/IS 8886. Information Processing. Data Communications. Data Link Service Definition for Open System Interconnection.

11. ISO/DIS 8348. Information Processing Systems. Data Communications. Network service Definition.

12. ISO/DIS 8648. Information Processing Systems. Data Communications. Internal Organization of the Network.

13. CCITT. VII —th Plenary Assembly. Document N7. Recommendation X.25. Interfase Between Data Terminal Equimpment (DTE) and Data

14. Circuit Terminaiting Equipment (DCE) for Terminals Operating in Packet Mode en Public Data Network Recommendation X.25. Orange Book. Geneva" 1980. 129 p.

15. CCITT. VIII —th Plenary Assembly. Document N58. Recommendation X.25. Malaga— Torremolinos. Recommendation X.25. Red book. — Ganeva~ 1984,- 180 p.

16. ГОСТ 26556 —85. Элементы процедур передачи информации и форматы пакетов в сетях передачи данных с коммутацией пакетов, ориентированных на виртуальные соединения.

17. ISO/IS 8878. Information Processing Systems. Data Communications. Use of X.25 to Provide the OSI Connection — Mode Network Service.

18. ISO/DIS 8208. Information Processing Systems. Data Communications. X.25 Packet Level Protocol for Data Terminal Equipment.

19. ISO/DIS 8348/DADI. Information Processing Systems. Data Communications. Network Service Definition. Addendum I Connectionless Mode Transmission.

20. ISO/DIS 8473. Information Processing Systems. Data Communications. Protocol for Providing the Connectionless Mode Network Service.21 .ISO/DIS 8473/DADI. Information Processing Systems. Data

21. Communications. Protocol for Providing the Connectionless Mode Network Service. Addedum I. Provision of the underlying Service Assumed by ISO 8473.

22. ISO/IS 8072/ADDENDUMI. Information Processing Systems. Open Systems Interconnection. Transport Service Definition. Connectionless Mode Transmission.

23. ISO/DIS 8602. Information Processing Systems. Open Systems Interconnection. Protocol for Providing Connectionless Mode Transport Service.

24. ISO/IS 8073. Information Processing Systems. Open Systems Interconnection. Connection Oriented Transport Protocol specificacion.

25. ISO/IS 8073/pDAD 2.2. Information Processing Systems. Open Systems Interconnection. Connection Oriented Transport Protocol specificacion. Class Four Operation Over Connectionless Network Service.

26. ISO/IS 8073/AD I. Information Processing Systems. Open Systems Interconnection. Connection Oriented Transport Protocol specificacion. Network Connection Managment Subprotocol.

27. ISO/IS 8881. Information Processing Systems. Data Communications. Use of the X.25 Packet Level Protocol in Beal Area Network.

28. ISO/IS 8326. Information Processing Systems. Open Systems1.terconnection. Basic Connection Oriented Session Service Definition.

29. ISO/IS 8327. Information Processing Systems. Open Systems Interconnection. Basic Connection Oriented Session Protocol Specification.

30. ISO/IS 8822. IPS. OSI. Connection Oriented Presentation Service Definition.

31. ISO/IS 8823. IPS. OSI. Connection Oriented Presentation Protocol Definition.

32. ISO/IS 8824. IPS. OSI. Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN. 1).

33. ISO 7498/ADD3. IPS. OSI. Definition of Application Common Service Elements.

34. ISO/IS 8650/1. IPS. OSI. Specification of Protocol for application Common Service Elements. Part 1: Basic Kernel Sibset.

35. ISO/IS 8649/3. IPS. OSI. Definition of Application Common Service Element. Part 3: Commitmen, Concurency and Recovery.

36. ISO/IS 8650/3. IPS. OSI. Specification of protocols for Application Common Service Elements. Part 3: Commitment, Concurrency and Recovery.

37. The ARPANET Telnet Protocol: it's Purpose, Principles Implementation and Impact on Last Operating System Desing / J. Davidson, W. Hathaway, J. Postel et al.// Proc. of 5 —th Data Communication Symposium. —1977.

38. Barber D.L.A. The Role Nature of a virtual Terminal // Computer Communication Review. —1976. —7 (3). — 5 p.

39. IFIP WS 6.1. Proposal for a Standart Virtual Terminal Protocol. INWG Protocol Note 91, 1978.

40. ISO/IS 9040. IPS. OSI. Virtual Terminal Service Basic Class.

41. ISO/IS 9041. IPS. OSI. Virtual Terminal Protocol Basic Class.

42. ISO/IS 8831. IPS. OSI. Job Transfer and Manipulation concepts and Services.

43. ISO/IS 8832. IPS.OSI.Specification of the Basic Class Protocol for Job Transfer and Manipulation.

44. ARPRNET RFC 407 Bressler R., Guida R., Mc Kenzie A. Remote job Entry Protocol. -1972.

45. Neiquis N. File Transfer Protocol. -RFC 542, 1973.

46. Якубайтис Э.А. Комплекс сетевых стандартов MAP/TOP / САИ//Автоматика и вычислительная техника. — 1988. — №2.— С.3 — 7.

47. Зайцев С. С. Формальное описание протокольных стандартов и их реализаций // Автоматика и телемеханика, №5. — 1988. — С. 143-151.

48. Зайцев С. С., Мурадян Н.А. ВЕРСИЯ — система верификации сетевых протоколов// Проблемы информационных систем. — М.: МЦНТИ. 1983. - С. 150-155.

49. Сетевое программное обеспечение МВК "Эльбрус" / Ю.И.Григорьев, С.С.Зайцев, М.И.Кравцунов, И.В.Тарасенко // Пятая Всесоюзная конференция "Вычислительные сети коммутации пакетов". — Рига, 1987.— Т.1. —С.249 —253.

50. Ю.М.Горностаев, В.И.Дрожжинов. Сетевая интеграция автоматизированного машиностроительного рпоизводства на базе протоколов связи MAP/TOP. М.: МЦТИ.- 1988. -123 с.

51. Зайцев С.С., Кравцунов М.И., Ротанов С.В. Сервис открытых информационно — вычислительных сетей. — М.: Радио и связь. — 1990. -235 с.

52. Сетевая .организация распределенных систем управления.

53. Методические рекомендации под ред. Жаровского С.Н. — Киев: Общество "Знание" УССР,- 1990. 23 с.Ч