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

            Схема модели OSI представлена на рисунке 1, который иллюстрирует процесс перемещения информации по сети.

Рисунок 1. Схема модели OSI.

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

В нашей системе будут передаваться небольшие объемы информации, большую часть времени канал передачи данных будет свободным, поэтому скорость передачи может быть невысокой. Расстояние, на которое будет передаваться информация также невелико. При этом нам необходимо использовать минимально возможный диапазон используемых частот. Следовательно, мы можем использовать канал с постоянными характеристиками, данные будут передаваться на одной частоте, но в разные временные промежутки. Используем модуляцию QPSK. Данный вид модуляции обеспечит оптимальное для нашей системы соотношение между скоростью передачи информации и ее помехозащищенностью. В нашей системе должна использоваться минимальная мощность излучения передатчика. В связи с этим целесообразно применить также сверточное кодирование со скоростью равной 1/2 (на 1 информационных бита будет приходиться 2 избыточных), и перемежение. Эти меры позволят снизить мощность передатчика, сохранив надежность передачи информации. Также в нашей системе будет использоваться битовая и символьная синхронизация. Битовая будет осуществляться с помощью системы фазовой автоподстройки частоты, а символьная – путем извлечения таймерного сигнала на приемной стороне с помощью узкополосного фильтра, настроенного на переданную таймерную частоту. Таймерный сигнал будет определять моменты стробирования демодулируемого сигнала. Приемник должен знать не только частоту стробирования, но и тот момент времени, в который необходимо взять отсчеты внутри каждого символьного интервала. Схема физического уровня системы представлена на рисунке 2.

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

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

Подуровень управления доступом к среде (MAC) отвечает за механизм доступа к каналу связи. В нашей системе нет конкурентной борьбы за канал. Каждое устройство получает доступ к каналу в определенные промежутки времени. Поэтому наш канальный уровень можно не разделять на два подуровня, он будет состоять только из уровня логической передачи данных. Опишем схему доступа устройств к канальному ресурсу. Приемопередатчики на светильниках через равные промежутки времени отправляют информацию о своем состоянии на ТУС. Каждый приемопередатчик отправляет данные по очереди (подробнее это описано в первой части КП). Время задержки передаваемых данных каждого светильника относительно друг друга закладывается на стадии монтажа.  Время через которое эти данные обновляются, задает пользователь. В интервал времени между обновлениями информации канал свободен для передачи команд светильникам. Если получится так, что пользователь будет менять профили освещения в тот момент, когда данные о состоянии светильников будут обновляться, система просто дождется окончания обновления (это займет очень короткий промежуток времени), а затем по очереди передаст каждому светильнику команду изменения мощности. Но возможна также ситуация, при которой приемопередатчики начнут отправлять обновленную информацию о светильниках на ТУС в момент времени, когда ТУС отправляет им команды об изменении профиля освещения. Чтобы этого не произошло, перед изменением профиля освещения ТУС должен отправить всем светильникам оповещение о том, что сейчас начнется передача команд. После этого оповещения светильники не будут отправлять обновленные данные о своем состоянии на ТУС. Далее ТУС отправляет команды о смене профиля освещения, после чего информирует все светильники о том, что команды переданы и может передаваться обновленная информация о состоянии температуры и мощности. Рассмотрим момент времени, когда обновленная информация со всех светильников была передана. Если данные с одного или нескольких светильников были приняты неверно, ТУС отправляет этим светильникам запрос на повторную передачу. Светильники, которые успешно передали данные, сразу же переходят в режим сна. Немного иначе происходит передача команд светильникам. ТУС передает по очереди команды каждому светильнику и после каждой команды получает подтверждение. Если подтверждение успешного приема не приходит, команда отправляется повторно. На рисунке 3 приведена схема приема информации от светильников.

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

            На рисунке 3 зеленым цветом обозначены сведения от светильников, успешно принятые ТУС; красным – неверно принятые, или не принятые вообще; голубым – запросы ТУС на повторную передачу. Слева обозначены номера светильников. На рисунке 4 представлена схема отправки команд светильникам от ТУС.

Рисунок 4. Отправка команд светильникам от ТУС.

            На рисунке 4 оранжевым цветом обозначены оповещения светильников о том, что сейчас начнется передача команд (светильникам от ТУС); розовым – команды изменения мощности светильников (светильникам от ТУС); синим – подтверждения светильников о том, что команды получены (ТУС от светильников); фиолетовым – оповещения светильников о том, что передача команд закончена (светильникам от ТУС); зеленым – плановая передача информации о характеристиках светильников (ТУС от светильников).

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

На физическом уровне структура пакета будет одинакова для всех его типов. Она будет состоять из следующих полей: поля канала коррекции частоты; поля синхронизации; информации, закодированной сверточным кодером и индикатора завершения пакета. Поле канала коррекции частоты необходимо для подстройки несущей частоты,  так как из-за разницы в работе генераторов частоты могут не совпадать. Поле синхронизации служит для передачи меток синхронизации, по которым будет происходить тактовая синхронизация и настройка ФАПЧ приемников. Данные кодируются сверточным кодером,  т.е в соответствии с заданной скоростью кодирования к информационным битам добавляются проверочные биты и после этого происходит передача. Индикатор завершения пакета необходим для обозначения его границ.

На канальном уровне, структуры пакетов различных типов будут отличаться. Начнем наш обзор с пакетов, передача которых осуществляется от светильника к ТУС. Всего в нашей системе существует два типа таких пакетов. На рисунке 5 представлена структура пакета с помощью которого происходит обновление информации о состоянии характеристик светильника. Пакет состоит из следующих полей: индикатора начала пакета; уникального номера светильника; идентификатора информационного типа пакета; информации о температуре и мощности (то, ради чего осуществляется передача пакета); поля контрольной суммы. Индикатор начала пакета необходим для обозначения его границ. УН светильника информирует ТУС о том, с какого именно светильника пришли данные. Наличие идентификатора информационного пакета говорит приемнику о том, что это пакет, содержащий именно данные о состоянии светильника, а не пакет какого-либо другого типа. Поле контрольной суммы служит для индикации целостности пакета, при вычислении контрольной суммы приемник понимает, верно принят пакет или нет.

Рисунок 5. Структура пакета с информацией о состоянии характеристик светильника (передача осуществляется от светильника к ТУС).

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

Рисунок 6. Структура пакета, подтверждающего успешный прием светильником команды от ТУС  (передача осуществляется от светильника к ТУС).

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

Рисунок 7. Структура пакета, запрашивающего повторную передачу данных о состоянии светильника в случае если обновленные данные по какой-либо причине не были приняты или были приняты с ошибкой. (передача осуществляется от ТУС к светильнику).

Рисунок 8. Структура пакета, оповещающего светильники о том, что сейчас начнется передача команд, изменяющих профиль освещения (передача осуществляется от ТУС к светильнику).

Рисунок 9. Структура пакета, изменяющего профиль освещения светильника (передача осуществляется от ТУС к светильнику).

Рисунок 10. Структура пакета, оповещающего светильники о том, что передача команд, изменяющих профиль освещения закончена (передача осуществляется от ТУС к светильнику).

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

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

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

            Рассмотрим диаграмму состояний светильников. Возможны четыре варианта состояний:

-          спящий режим;

-          ожидание получения команд (в этом режиме светильник не отправляет регулярные сведения о своем состоянии на ТУС);

-          получение команд;

-          отправка данных (информации о состоянии светильников или подтверждения выполнения команды).

Если пользователь не отправляет команды о запросе характеристик светильника или изменении его яркости, то светильник функционирует, чередуя два режима своей работы: спящий режим и регулярную отправку данных о своем состоянии. Однако, пользователь может вмешаться в функционирование системы, если изменит профиль освещения или принудительно обновит данные. (рисунок 11). Напомню, что команды S1 и S2 являются командами, которые соответственно переводят светильник в режим ожидания получения команд и переводят обратно в спящий режим.

Рисунок 11. Диаграмма состояний светильников.

Литература:

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

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