Построение иерархической модели системы

Построим иерархическую модель системы в соответствии с рекомендациями OSI. Эталонная модель OSI, иногда называемая стеком OSI  и представляет собой 7-уровневую сетевую иерархию, разработанную Международной организацией по стандартам (International Standardization Organization - ISO). Каждому уровню с некоторой долей условности соответствует свой операнд — логически неделимый элемент данных, которым на отдельном уровне можно оперировать в рамках модели и используемых протоколов: на физическом уровне мельчайшая единица — бит, на канальном уровне информация объединена в кадры, на сетевом — в пакеты (датаграммы), на транспортном — в сегменты. Любой фрагмент данных, логически объединённых для передачи — кадр, пакет, датаграмма — считается сообщением. Именно сообщения в общем виде являются операндами сеансового, представительского и прикладного уровней.


Рисунок 1. Уровни модели OSI, подробно рассмотренные в КП.

Начнем описание модели с физического уровня. Это самый нижний в модели OSI. Этот уровень осуществляет передачу неструктурированного потока бит по физической среде. Физический уровень обеспечивает механические, электрические, функциональные и процедурные средства активизации, поддержания и деактивизации физических соединений для передачи данных между канальными объектами. Функции уровня сводятся к активизации и деактивизации физического соединения, а также передаче данных. Физический уровень также формирует сигналы, которые переносят данные, поступившие от всех вышележащих уровней. Кроме того, здесь определяется способ передачи данных по сети. Физический уровень осуществляет передачу битов (нулей и единиц) от одного устройства к другому. Уровень отвечает за кодирование данных и синхронизацию битов, гарантируя, что переданная единица будет воспринята именно как единица, а не как ноль. Также физический уровень устанавливает длительность каждого бита и способ перевода бита в соответствующие электрические оптические или какие-либо другие импульсы, передаваемые по сети. Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. В нашей системе на физическом уровне мы должны выбрать тип модуляции, помехоустойчивого кодирования, параметры синхронизации и перемежения. Наша система относительно проста в том плане, что в ней нет подвижных объектов, передаются небольшие объемы информации и на небольшие расстояния, поэтому мы можем поступить следующим образом. Установим в нашей системе только один профиль функционирования. Параметры профиля определим позднее в последующий частях КП. 


Рисунок 2. Схема физического уровня модели.

Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Канальный уровень подразделяется на 2 подуровня: подуровень управления доступом к среде MAC (Media Access Control) и подуровень  логической передачи данных LLC (Logical Link Control). MAC подуровень отвечает за то, каким образом организуется множественный доступ в системе. Однако в нашей системе ресурсы канала в разные моменты времени будут строго распределяться между устройствами. Это распределение будет закладываться в память устройств еще на стадии монтажа. 


Сценарий взаимодействия устройств

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


Рисунок 3. Прием информации центром БС от светильников.

Теперь рассмотрим как происходит передача команд светильникам. Прежде чем передать светильникам какую-либо команду ЦБС оценивает время оставшееся до планового приема информации от светильников. Если времени остается мало и его недостаточно для передачи команд, ЦБС сначала дожидается информационных данных от светильников, а уже потом отправляет команды. Объемы информации, участвующие в обмене очень маленькие, а потому время их приема и передачи соответственно тоже очень мало. Поэтому пользователь не заметит большой задержки в изменении профиля освещения. Схема отправки команд представлена на рисунке 4. Слева цифрами обозначены id светильников, синим цветом обозначены команды ЦБС, передаваемые светильникам, красным – отчеты светильников об успешном приеме команды. ЦБС по очереди отправляет пакеты с командами каждому из тех светильников, мощность которых необходимо поменять. Сначала команды отправляются светильникам с меньшим id, а потом с большим, по порядку. Отправив команду конкретному светильнику, ЦБС ждет пакета подтверждения успешного приема команды. Если этот пакет не приходит, ЦБС повторно отправляет команду. После получения пакета подтверждения, другая команда отправляется следующему светильнику и так далее. 


1-6 - номера светильников

Рисунок 4. Передача команд светильникам.


Типы полей пакетов

        Если рассмотреть поля из которых будут состоять пакеты более детально, то получим следующую картину. На физическом уровни пакеты будут выглядеть одинаково. Каждый пакет будет состоять из поля коррекции частоты, поля синхронизации, поля с информацией и флага разделения границ каналов. Поле канала коррекции частоты требуется для подстройки несущей частоты, а флаг в конце пакета необходим для того чтобы приемник мог определить где закончился один пакет и начался другой. Поле синхронизации служит для передачи меток синхронизации, по которым будет происходить тактовая синхронизация и настройка ФАПЧ приемников. Данные кодируются сверточным кодером,  т.е в соответствии с заданной скоростью кодирования к информационным битам добавляются проверочные биты и после этого происходит передача. Индикатор завершения пакета необходим для обозначения его границ. На канальном уровне структуры пакетов также будут похожи. Отличаться они будут только полем информационных данных. В зависимости от типа пакета в этом поле может представлять собой либо данные о температуре и мощности, либо команду изменения профиля освещения, либо отчеты об успешном приеме команды или данных. Таким образом в нашей системе все пакеты по своей структуре можно грубо разделить на четыре основных типа, которые представлены на рисунках 5, 6, 7 и 8. На нечетных рисунках представлены пакеты, передаваемые в направлении от светильника к ЦБС, а на четных рисунках – в обратном направлении.



Рисунок 5. Пакет с информацией от светильника.


Рисунок 6. Пакет с подтверждением успешного приема данных от светильника.


Рисунок 7. Пакет с подтверждением успешного приема команды от ЦБС.


Рисунок 8. Пакет с командой изменения профиля освещения.

            Сетевой уровень - это комплексный уровень, который обеспечивает возможность соединения и выбор маршрута между двумя конечными системами. В нашем КП рассматривается взаимодействие объектов в пределах одной сети, поэтому сетевой уровень мы рассматривать не будем.

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

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

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


Рисунок 9. Сценарий взаимодействия ЦБС и светильника.


Список литературы:

1.      Бакке А.В. "Лекции по курсу ССПО".

2.      Описание эталонной модели OSI http://www.fstuit.org/publ/4-1-0-2


Ссылки на предшествующие сообщения:

http://omoled.ru/publications/view/314