Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
протокол BITBUS.doc
Скачиваний:
16
Добавлен:
23.08.2019
Размер:
228.86 Кб
Скачать

4 Логическая структура и формат данных в сети bitbus

Кратко рассмотрим логическую организацию и технологию передачи данных по сети. В сети BITBUS обязано быть одно выделенное устройство (узел сети), называемое ведущим (обычно употребляется англоязычный термин master). Все остальные узлы сети являются ведомыми (slave). В одной сети BITBUS может быть объединено до 250 ведомых устройств. Ведомое устройство имеет уникальный адрес, произвольно выбираемый из диапазона от 1 до 250 и устанавливаемый аппаратно или программно. Кроме того, каждый узел сети может иметь устройство-расширение (extention). Это очень важное свойство адресации. Дело в том, что стандарт не накладывает никаких ограничений ни на физическую, ни на логическую реализацию канала связи между узлом сети и его расширением. Это позволяет подключать к сети BITBUS разнообразные устройства в качестве расширений узлов сети, при этом техническая реализация канала расширения может быть как последовательным каналом RS-232 со старт-стопным протоколом, так и скоростной параллельной шиной. На рисунке 5 показана в общем виде логическая структура сети BITBUS:

Рисунок 5. Общий вид логической структуры сети BITBUS.

Вся работа сети строится на принципе обмена сообщениями. Ведущий узел посылает сообщения-запросы конкретным ведомым узлам, которые отвечают сообщениями-ответами. Отличие ведущего узла от ведомых и заключается в инициативной посылке сообщений, которая разрешена только "мастеру" сети. Вообще говоря, любой узел сети станет "мастером", если пошлет по сети сообщение-запрос, однако после этого никакой другой узел уже не должен "проявлять инициативу". Обычно функции "мастера" сети BITBUS возлагаются на узел, который (в совокупности со своим расширением, если оно есть) обладает большей, чем другие, вычислительной мощностью, так как все потоки информации, в том числе и между ведомыми узлами, организуются ведущим узлом. Строго говоря, сообщения пересылаются не между узлами, а между задачами. Каждый узел сети BITBUS функционирует под управлением многозадачной операционной системы реального времени, аналогичной по свойствам iRMX51 фирмы INTEL (далее мы будем употреблять условное название OS). Кроме того, в каждом из узлов сети под управлением OS обязана функционировать одна сетевая задача, которая, собственно, и производит всю работу по пересылке сообщений. Поскольку эта задача также выполняет стандартные команды, содержащиеся в сообщениях, ее традиционно принято называть задачей RAC (Remote Access and Control). Кроме сетевой задачи в узлах сети могут функционировать и другие задачи, носящие прикладной характер. Как правило, каждое устройство с интерфейсом BITBUS уже имеет "прошитое" ПО (firmware), содержащее OS и RAC, поэтому пользователю нет необходимости заботиться о системной поддержке обмена по сети. Заметим, что все это относится непосредственно к узлам сети. К программному обеспечению расширений не предъявляется никаких специальных требований. Рассмотрим типичный вариант: персональный компьютер исполняет роль ведущего узла. С точки зрения адресации "мастером" сети является адаптер сети BITBUS, работающий в составе этого компьютера и содержащий встроенное ПО, включающее OS и RAC. Сам компьютер является его расширением. Программа на компьютере может работать под управлением MS-DOS или операционной системы реального времени, например QNX или OS-9. Эта программа передает сообщения-запросы и принимает сообщения-ответы с помощью соответствующего драйвера. Этот драйвер обеспечивает передачу сообщений между ПО компьютера и адаптера, а передача сообщений собственно по сети контролирует адаптер. Таким образом, ПО компьютера не загружается собственно сетевыми функциями.

В соответствии с канальным протоколом сети BITBUS SDLC полный формат сообщения содержит служебные поля: флаги начала и конца сообщения, счетчики переданных и полученных сообщений, код управления, контрольный полином и т.п., которые интерпретируются исключительно системным ПО (задачей RAC) и невидимы для прикладных программ. Мы рассмотрим прикладную часть сообщения, с которой имеют дело прикладные программы. Структура всех сообщений проста - каждое сообщение содержит обязательный заголовок из 5 байт, а также (как правило) информационную часть (рисунок 6).

Рисунок 6.

Длина сообщения может быть до 250 байт, однако наиболее часто используется формат сообщений длиной 20 байт. Адрес узла дополняется флагами, которые указывают, является ли источником и приемником сообщения сам узел или его расширение. Нулевой идентификатор задачи приемника указывает на то, что сообщение адресовано задаче RAC, которая в этом случае выполнит посланную команду из стандартного набора команд. Стандартный набор команд включает команды сброса, управления задачами, получение информации об узле, доступа к памяти и вводу-выводу узла. Данные интерпретируются в соответствии с кодом команды. Таким образом, даже при отсутствии какого-либо прикладного ПО на ведомом устройстве, его использование в качестве удаленного УСО обеспечивается системной задачей RAC. Если сообщение адресовано прикладной задаче или программе в расширении узла, то интерпретация команды и формат данных определяются прикладной программой. Сообщения-ответы имеют структуру, совпадающую со структурой сообщений - запросов, при этом вместо команды возвращается статус завершения операции. На практике наиболее употребим команды чтения и записи в память, которые позволяют реализовать гибкое взаимодействие с прикладными программами элементов распределенной системы.