Содержание к диссертации
Введение
Глава 1. Анализ мирового опыта построения распределенных систем управления производством 7
1.1 Типичные компоненты распределенных систем управления 7
1.2 Анализ мирового опыта создания стандартов открытых коммуникационных систем автоматизации предприятия на примере проектов MAP и ТОР 9
1.2.1 Конструктивные блоки MAP/TOP 9
1.3 Эталонная модель ВОС - основа построения открытых информационно-управляющих систем 16
1.3.1 Структура уровней ВОС 17
1.3.2 Принципы реализации сервиса модели ВОС 22
1.3.3 Сервис транспортного уровня 27
1.3.3.1 Транспортный сервис с соединением 32
1.3.4 Сервис сессионного уровня... 37
1.3.4.1 Новые понятия, введенные в сессионном сервисе 37
1.3.5 Общий прикладной сервис ...47
1.3.5.1 Базовое ядро общих прикладных услуг 50
1.3.5.2 Специфический прикладной сервис 56
1.4 Соотношение стандартов MAP, ТОР и эталонной модели ВОС.61
1.5 Выводы 63
Глава 2. Анализ сетевых программных средств TCP/IP в UNIX и Windows. Постановка задачи 64
2.1 Введение в TCP/IP .66
2.2 Общее описание набора протоколов TCP/IP 69
2.2.1 Формирование дейтаграмм на уровне TCP 73
2.2.2 Работа сданными на уровне UDP 76
2.2.3 Работа сданными на уровне IP 77
2.2.4 Прохождение дейтаграмм через уровень Ethernet 78
2.3 Обзор Прикладного Уровня TCP/IP 80
2.4 Обзор методов сетевого программирования TCP/IP 83
2.5 Сравнение TCP/IP с Моделью Сетевой Архитектуры МОС ВОС86
2.6 Постановка задачи исследования 88
2.7 Выводы 90
Глава 3. Моделирование сервиса эталонной модели ВОС над транспортным уровнем TCP/IP и построение на его основе экспериментальной распределенной системы управления 92
3.1 Определение уровня взаимодействия набора протоколов TCP/IP и верхних уровней ВОС 92
3.2 Разработка схемы сервиса моделируемых уровней 93
3.3 Моделирование общего сервиса разработки распределенных систем управления 94
3.4 Разработка специфического интерфейса транспортного уровня. 101
3.5 Разработка принципов обслуживания на сессионном и представительском уровнях 103
3.6 Моделирование базового ядра прикладных услуг 107
3.7 Моделирование группы услуг прогнозирования изменения передаваемых данных 111
3.8 Разработка схемы диспетчеризации сообщений распределенной системы управления 115
3.9 Разработка модели применения сервиса построения распределенной системы управления 118
3.10 Выводы
- Анализ мирового опыта создания стандартов открытых коммуникационных систем автоматизации предприятия на примере проектов MAP и ТОР
- Формирование дейтаграмм на уровне TCP
- Обзор методов сетевого программирования TCP/IP
- Моделирование общего сервиса разработки распределенных систем управления
Введение к работе
Одним из наиболее приоритетных направлений научно — технического прогресса являются работы по созданию и внедрению в мелкосерийном и серийном машиностроительном производстве разнообразных средств комплексной автоматизации, в том числе распределенных систем управления производством (РСУ). В состав этих систем признано необходимым включать системы автоматизированного проектирования машин, технологических процессов, а также автоматизированные системы (АС) планирования, технической подготовки и управления производством.
При решении проблем комплексной автоматизации машиностроения важнейшее значение имеют вопросы унификации программных и технических средств обработки данных, организации единой коммуникационной сети, связывающей робототехнические устройства, станки с ЧПУ, контрольно — измерительные и управляющие приборы.
Сети ЭВМ имеют большие потенциальные возможности для обмена информацией. Тем не менее, использование оборудования различных поставщиков, различных подходов к форматированию данных, проектированию систем связи и стандартам порождает сложные проблемы. Следовательно, существует реальная необходимость в стандартах по обмену информацией между различными вычислительными системами многих производителей вычислительной техники.
Исторически для достижения совместимости разработчики распределенных систем применяли частные сетевые системы одного производителя или ограниченной группы производителей. В основном, интеграция компьютерных систем различных производителей требует разработки заказного аппаратного и программного обеспечения, что неблагоприятно сказывается на стоимости и эффективности разрабатываемой системы. Эта ситуация чаще ведет разработчиков к
выбору систем, отвечающих требованиям совместимости с существующими системами, чем к выбору наиболее рациональных решений прикладных задач. В свою очередь, это приводит к развитию автономных участков, которые не слишком подходят для взаимослияния в интегрированное целое.
В последние годы наметились большие успехи в коммуникационной технологии, обеспечивающей связь между машинами различных производителей. Эти успехи основываются на философии открытой архитектуры. Такая открытая архитектура определена в эталонной модели ВОС/МОС (взаимодействие открытых систем международной организации по стандартизации).
Архитектура открытых систем (АОС) использует принятые стандартные протоколы для реализации связи между компьютерами. Работу по определению этих стандартных протоколов для эталонной модели ВОС возглавляет МОС. Эти протоколы имеют общее название — протоколы АОС. Цель ВОС — построение основы для организации всемирной сети передачи данных. Стандартизация информационных коммуникаций означает для разработчиков распределенных систем получение возможности выбирать компьютерные устройства и связанные с ними ресурсы, наиболее подходящие к их требованиям.
С другой стороны, имеются другие концепции развития коммуникационных систем. Имеется в виду, в частности, набор протоколов Управления Перспективных Исследований Министерства Обороны США, известный как набор протоколов TCP/IP. В силу исторических причин, а именно бурного развития Internet в последние годы, TCP/IP получил чрезвычайно широкое распространение в мире. Именно поэтому существует объективная потребность в построении распределенных систем управления на основе сетей с этими протоколами.
Нет сомнений в том, что архитектура ВОС более богата и сложна чем архитектура набора протоколов TCP/IP. Сервис ВОС
предоставляет максимум возможностей для разработки надежных управляющих систем, так как он построен с учетом многолетнего опыта применения сетевых технологий для автоматизации промышленных предприятий. В данной работе решается задача построения сервиса для разработчиков распределенных систем управления, работающих в сетях с протоколами TCP/IP. Создаваемый сервис должен вобрать в себя богатство возможностей модели ВОС, а также простоту и открытость протоколов TCP/IP. Для этого необходимо провести анализ обеих архитектур, определить место TCP/IP в семиуровневой модели ВОС, и разработать методику построения прикладного сервиса над средствами поддержки протоколов TCP/IP.
Анализ мирового опыта создания стандартов открытых коммуникационных систем автоматизации предприятия на примере проектов MAP и ТОР
В рамках проекта MAP/TOP была разработана концепция конструктивного блока. Она позволяет разработчикам и изготовителям сетевого оборудования учитывать требования заказчиков за счет соотношения этих требований со спецификациями протоколов и служб проекта MAP/TOP. Далее осуществляется выбор необходимых протоколов, их параметров, функциональных элементов и факультативных средств, обеспечивающих как соответствие конечного сетевого продукта проекту MAP/TOP, так и возможность совместной работы с сетевым оборудованием других изготовителей. С точки зрения заказчика сетевого оборудования концепция конструктивного блока позволяет точно определить набор функций сетевого оборудования, удовлетворяющий потребностям заказчика.
В проекте MAP/TOP выделяются следующие виды систем, которые строятся из конструктивных блоков: оконечные — системы ТОР, в которых выполняются прикладные функции, свойственные учреждению (электронная почта, конструирование и другие), а также системы МАР, в которых выполняются прикладные функции, свойственные планированию и управлению производством; ретрансляторы, к числу которых относятся: коммутатор MAP/TOP, предназначенный для сопряжения на сетевом уровне различных ЛВС и выхода на крупномасштабные сети связи типа Х.25; мост MAP, служащий для сопряжения на канальном уровне локальных сетей связи MAP; повторитель MAP, предназначенный для сопряжения на физическом уровне локальных сетей связи MAP; специальные оконечные системы MAP/TOP — MAP —ЕРА (Enchenced Performance Architecture, архитектура с повышенной производительностью) и мини —MAP, предназначенные для уровня ГПМ, робототехнического комплекса или управления непрерывными технологическими процессами. Основные требования к оконечным системам такого типа — работа в реальном масштабе времени, низкая стоимость.
Такая дополнительная классификация необходима для идентификации типов законченных программно — аппаратных систем, соответствующих требованиям проекта MAP/TOP.
Описание каждого конструктивного блока MAP/TOP имеет имя и содержит: описание функции, реализуемой блоком; список стандартов сетевых служб и протоколов Международной организации по стандартизации, их параметров и набор факультативных средств, подлежащих реализации в блоке для обеспечения выполнения в нем соответствующих функций; правила соединения с другими по функциям блоками для получения комбинаций, удовлетворяющих спецификациям проекта MAP/TOP. Набор конструктивных блоков для оконечных систем представлен на рис. 1—2. Блоками, обеспечивающими надежную передачу данных между оконечными системами, являются: блок доступа в случайную шину, который позволяет подключать оконечную систему ТОР к моноканальной или поликанальной ЛВС со случайным доступом. Он обеспечивает надежную передачу данных между удаленными оконечными системами ТОР. Блок доступа в маркерное кольцо, позволяющий подключать оконечную систему ТОР к ЛВС типа маркерного кольца. Он обеспечивает надежную передачу данных между удаленными оконечными системами ТОР. Блок доступа в маркерную шину MAP, который позволяет подключать оконечную систему MAP к моноканальной или поликанальной ЛВС типа маркерной шины. Он обеспечивает надежную передачу данных между удаленными оконечными системами MAP или ТОР. Блок доступа в сеть Х.25, который позволяет подключать оконечную систему ТОР непосредственно к сети Х.25. Он обеспечивает надежную передачу данных между удаленными оконечными системами ТОР, подключенными непосредственно к сети Х.25.
Блок быстрого доступа в маркерную шину, позволяющий подключать оконечную систему MAP — ЕРА или мини — MAP к моноканальной ЛВС типа маркерной шины, обеспечивает надежную передачу данных в реальном масштабе времени между удаленными оконечными системами MAP —ЕРА и мини —MAP.
Следующие блоки обеспечивают обмен структурированными данными между оконечными системами, а также поддерживают функционирование и управление сетью: блок электронной почты, который наделяет оконечную систему функциями транзитного хранения и передачи сообщений между конечными пользователями и прикладными процессами — абонентами; блок удаленного доступа к файлам, который наделяет оконечную систему MAP/TOP функциями, необходимыми прикладному процессу для удаленного доступа к файлам и для удаленного управления файлами; блок удаленного доступа с терминала, который предоставляет пользователям терминалов возможность связаться и получить доступ в оконечную систему MAP/TOP независимо от типа терминала и ЭВМ, на базе которой реализована оконечная система. Для этого в данном блоке используется протокол виртуального терминала, который позволяет оконечной системе, содержащей функции терминального эмулятора, связаться с оконечной системой MAP/TOP, содержащей интерактивную прикладную программу.
Формирование дейтаграмм на уровне TCP
Протокол управления передачей TCP отвечает за помещение сообщения в дейтаграммы, повторную сборку их на другом конце, повторную посылку потерянных дейтаграмм и расположение их в правильном порядке. Для небольших сетей основная часть работы лежит на протоколе TCP.
При передаче TCP мультиплексирует сообщение, то есть разбивает его на части. Размер дейтаграммы выбирается минимальным из двух возможных на обоих концах соединения. На другом конце происходит демультиплексирование — сбор отдельных сообщений в единое целое. Информация, необходимая для демультиплексирования, содержится в заголовках дейтаграмм — нескольких дополнительных октетах в начале каждой дейтаграммы, соответствующих некоторому протоколу. В случае потери дейтаграммы TCP организует повторную ее отправку. В TCP/IP применяется несколько уровней демультиплексирования.
TCP не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в порт TCP, то прикладной процесс на другом конце соединения может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны не существует зависимости.
Заголовок TCP содержит 20 октетов. Наиболее важной информацией в данном заголовке являются сведения об источнике, получателе и порядковом номере. Информация об источнике и получателе передается в виде номеров портов.
Каждая дейтаграмма имеет порядковый номер. Он используется для того, чтобы получатель мог удостовериться в том, что он получил дейтаграммы в правильном порядке, и нет пропущеных дейтаграмм. TCP перечисляет не дейтаграммы, а октеты. Так, если имеются 500 октетов данных в каждой дейтаграмме, первая дейтаграмма будет нумероваться 0, вторая 500, следующая 1000, следующая 1500 и так далее. Контрольная сумма — это число, которое вычисляется путем сложения всех октетов дейтаграммы. Результат включается в заголовок. TCP на другом конце вычисляет контрольную сумму снова. Если они не равны, значит при передаче произошла ошибка, и данное сообщение отбрасывается. Формат дейтаграммы TCP представлен на Рис. 2-3. Номер в очереди-32 бита Номер подтверждения-32 бита Смещение данных - 4 бита Зарезервировано-6 бит Окно-1.6 бит Контрольная сумма-16 бит Указатель срочности- 16 бит Передаваемые данные- последние 500 октетов
Неупомянутые пункты заголовка связаны с управлением соединением. Получив дейтаграмму, получатель посылает обратно подтверждение. Этот принцип действует для дейтаграммы, у которой заполнено поле "Подтверждение". Например, посылка пакета с подтверждением 1500 означает, что получены все данные с номером октета до 1500. Если в разумный срок отправитель не получает подтверждения, данные посылаются снова. Поле "Окно" используется для контроля за количеством данных, находящихся в данный момент в транзите. Не практикуется ожидание одной дейтаграммой подтверждения о приходе предыдущей — это сильно замедлило бы передачу. Таким образом, каждый участник соединения указывает, сколько новых данных он в настоящее время подготовил к переработке, помещая номер октета в области "Окна". Как только компьютер получает данные, количество оставшихся в "Окне" данных уменьшается. Когда оно достигнет нуля, отправитель останавливает передачу. Когда приемник обрабатывает данные, он увеличивает содержимое "Окна", показывая, что он готов к приему большего количества данных. Часто одна и та же дейтаграмма может быть использована для подтверждения получения набора данных и для разрешения к посылке новых данных (обновлением поля "Окно"). Поле "Срочность" дает возможность одному концу указать другому, какой октет надо пропустить вперед при обработке. Это полезно для асинхронной передачи, например, когда вводится управляющий символ или другая команда, прерывающая вывод.
Протокол TCP используется в тех случаях, когда требуется гарантированная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать тайм — ауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol — протокол передачи файлов) и TELNET. Кроме того, TCP используют система X —Window, rep (remote copy — удаленное копирование) и другие прикладные программы. Но большие возможности TCP в свою очередь требуют большой производительности процессора и большой пропускной способности сети.
Протокол UDP является альтернативой TCP и находится на одном с ним уровне. UDP обеспечивает доставку дейтаграмм и не гарантирует ее выполнения. Он не поддерживает соединения с удаленным модулем UDP, то есть является протоколом передачи без установления логического соединения. К заголовку IP —пакета он добавляет четыре поля, два из которых — исходный порт и порт получателя — обеспечивают мультиплексирование информации между разными прикладными процессами, третье — контрольная сумма — позволяет поддерживать целостность данных. Поле длины сообщения указывает количество октетов в сообщении UDP, включая заголовок и данные. Минимальная длина — 8 октетов. В случае, если при получении дейтаграммы UDP от уровня IP оказывается, что поле контрольной суммы равно 0, это означает, что отправитель ее не подсчитывал. Таким образом, на уровне UDP подсчет контрольной суммы не является обязательным.
Прикладные процессы и модули UDP взаимодействуют через UDP — порты. Эти порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги (сервер), ожидает сообщений в порт, специально выделенный для этих услуг. Программа — сервер ждет, когда какая — нибудь программа — клиент запросит услугу. Общеизвестные номера портов являются стандартами Internet.
Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс — отправитель производит 5 записей в UDP — порт, то процесс — получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он не объединяет несколько сообщений в одно и не делит одно сообщение на части.
Обзор методов сетевого программирования TCP/IP
Для операционных сред UNIX и Windows существует ряд методов сетевого программирования. Все они предоставляют различный сервис и позволяют создавать различные по эффективности сетевые прикладные программы.
Одним из методов сетевого программирования в UNIX является использование библиотеки Транспортного Уровня ВОС (ТЫ). Данный метод соответствует стандарту транспортного уровня эталонной модели ВОС и позволяет посылать дейтаграммы на сетевой уровень с последующей их отправкой не только протоколами ВОС, но и протоколами TCP/IP. Производители UNIX —машин рекомендуют пользоваться при разработке сетевого программного обеспечения именно этим методом. Недостатком данного метода является отсутствие его поддержки в данный момент в среде Windows.
Другим, наиболее распространенным методом программирования сети является программирование с использованием сокетов. Сокет — базисный стандартный блок для основанного на сокетах межпроцессного взаимодействия. Сокет — оконечная именуемая точка связи. Каждый сокет при использовании имеет тип и один или более связанных процессов. Типы сокетов назначаются согласно их свойствам связи.
Существуют три типа сокетов: сокеты потока, обеспечивающие двунаправленный, надежный, последовательный и недублированный поток данных сообщения; дейтаграмные сокеты, поддерживающие двунаправленный поток данных, но не гарантирующие, что данные сообщения последовательны, надежны или недублированы; необработанные сокеты, дающие доступ к тем основным протоколам связи, которые поддерживают абстракции сокета. Процессы, связанные с сокетом, общаются через него. Сокеты связываются с сокетами того же самого типа. Однако, возможна связь и между сокетами различных типов, и основные протоколы связи должны это поддерживать.
Сокеты существуют внутри областей связи. Область диктует различные свойства сокета. Например, схема, используемая для именования сокета. В области связи UNIX сокеты именуются путями UNIX: сокет может быть назван /dev/foo.
Обычно сокеты обмениваются данными внутри одинаковой области. Возможно пересечение границ области, но только при выполнении некоторого процесса трансляции.
Сокеты могут поддерживать три области связи: область UNIX, используемая только для внутрисистемной связи; область Internet, используемая процессами, которые общаются через стандартные протоколы связи Internet — IP/TCP/UDP; необработанная область, обеспечивающая доступ к протоколам уровня компоновки сетевых интерфейсов (уникально для IRIX). Основные средства связи, обеспечиваемые каждой областью, имеют значительное влияние на интерфейс доступных пользователям возможностей сокетов, обеспечивая специфические для протокола свойства сокета, которые могут быть установлены или изменены пользователем. Например, сокеты, действующие в области UNIX, могут идентифицировать подмножество условий ошибок, которые возможны при действиях в области Internet.
Внутри каждой области для каждого типа сокета имеется один протокол. Код, который осуществляет протокол, поддерживает привязку имен к сокету, устанавливает соединения и передает данные между сокетами.
Сокеты в операционной системе Windows были разработаны на основе сокетов BSD UNIX и работают на основе тех же самых принципов.
Третьим методом сетевого программирования является RPC (Remote Procedure Call — вызов удаленной процедуры). RPC является методом высокоуровневой коммуникации, который позволяет разрабатывать сетевые приложения, используя вызовы процедур, скрывающие детали сетевой передачи. RPC реализует систему клиент/сервер. Независимость от аппаратного обеспечения достигается использованием механизма декодирования данных и преобразованием порядка байт стандарта XDR (external Data Representation — внешнее представление данных). Данный стандарт соответствует представительскому уровню ВОС и основан на стандарте Х.409.
Моделирование общего сервиса разработки распределенных систем управления
При построении любого программного сервиса необходимо разработать алгоритм его использования. Общая схема системы использующей разрабатываемый сервис, представлена на Рис. 3—11. На рисунке показана схема взаимодействия объекта распределенной системы управления с другими объектами через установленные прикладные ассоциации. Каждый объект распределенной системы может установить произвольное количество прикладных ассоциаций, руководствуясь решаемыми задачами. Программа управления объектом строится на основе разрабатываемого в работе сервиса.
Объект распределенной системы изображен на Рис. 3—12. Основными компонентами объекта являются: 1. Данные, отражающие состояние объекта и управляемой им части распределенной системы в целом.. 2. Диспетчер сообщений, организующий прием сообщений от установленных прикладных ассоциаций и передачу их в соответствующие процедуры обработки, а также отправку сообщений партнерам по распределенной системе. Эти действия диспетчер производит через находящиеся в области его данных очереди входных и выходных сообщений. 3. Процедуры обработки сообщений. Каждая процедура соответствует определенному типу сообщения и характеризуется приоритетом. 4. Список установленных объектом прикладных ассоциаций.. 5. Основной цикл программы, в котором производится непосредственное управление диспетчером сообщений, манипулирование данными объекта и оценка состояния объекта и управляемой им части системы (величина ее зависит от места объекта в иерархии системы). В соответствии с полученными данными принимаются решения о дальнейших действиях и рассылаются необходимые сообщения (команды). Алгоритм действий при выполнении основного цикла программы показан с помощью сети Петри, изображенной на Рис. 3—13. Позиции сети имеют следующее назначение: Р1 — подготовка данных к новому циклу программы управления; Р2 — получение из очереди выходящих сообщений очередного сообщения с наивысшим приоритетом; РЗ — передача подготовленного сообщения через соответствующую прикладную ассоциацию и удаление его из очереди выходящих сообщений; Р4 — обработка состояния установленных прикладных ассоциаций; прием сообщений и передача их в очередь входящих сообщений в соответствии с приоритетом; Р5 — выборка очередного сообщения с наивысшим приоритетом из очереди входящих сообщений; Р6 — передача сообщения в соответствующую процедуру обработки и удаление его из очереди; Р7 — оценка состояния объекта и части системы в целом; Р8 — принятие решений и рассылка необходимых сообщений партнерам по распределенной системе, а также организация новых прикладных ассоциаций.
Одной из основных частей основного цикла программы управления объектом является обработка состояния установленных прикладных ассоциаций, заключающаяся в получении и анализе сообщений, пришедших от партнеров по ассоциациям. С применением группы услуг прогнозирования изменения передаваемых по сети данных эта процедура усложняется. В данные, характеризующие прикладную ассоциацию, добавляется список структур данных, зарегистрированных для этой группы услуг. При обработке состояния ассоциации для объекта, передающего данные, и объекта, получающего их, существуют разные алгоритмы действий. Граф сети Петри, отражающей действия передающего данные объекта, изображен на Рис. 3— 14. X Рис. 3 — 14 Сеть Петри, отражающей действия объекта, передающего данные с использованием услуги прогнозирования изменения данных.
Позиции сети имеют следующее назначение: Р1 — подготовка данных к выполнению услуги; Р2 — вычисление прогнозируемых значений всех полей передаваемой структуры; РЗ — определение недопустимо изменившихся полей данных (прогноз не совпал с истинным значением на недопустимую величину); Р4 — формирование сообщения, если есть хотя бы одно поле, изменившееся на недопустимую величину; Р5 — заполнение истории передачи данных (если какая —то часть данных изменилась на допустимую величину, в историю заносится значение — прогноз) ; P6 — подготовка сообщения с данными синхронизации (полный пакет истинных данных).
Описание условий срабатывания переходов данной сети Петри приводится в Таблица 3 — 6. Позиции сети имеют следующее назначение: Р1 — подготовка данных к выполнению услуги; Р2 — вычисление прогноза значений всех полей структуры данных; РЗ — занесение данных в реальную структуры данных; Р4 — заполнение истории приема данных; Р5 — прием данных по сети (часть данных или данные синхронизации);
