Размещено на http://www.allbest.ru/

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ЗАДАНИЯ

2. ОБЗОРНО АНАЛИТИЧЕСКАЯ ЧАСТЬ

3. СПЕЦИАЛЬНАЯ ЧАСТЬ

4. ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ

5. ЛАЗЕРНОЕ ИЗЛУЧЕНИЕ И ЗАЩИТА ОТ ЕГО ВОЗДЕЙСТВИЯ

ВЫВОДЫ

СПИСОК ЛИТЕРАТУРЫ



ВВЕДЕНИЕ

Данная работа является частью ОКР «Разработка эскизного проекта с действующим макетным образцом судового лазерного комплекса для снижения ледовых нагрузок на суда и инженерные сооружения, работающие на континентальном шельфе» шифр «Ледорез-2.

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

Для решения этой задачи в составе комплекса предусмотрено различное оборудование.

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

В состав СЛК входит следующее оборудование:

· два лазера с постоянно излучаемой мощностью 100 кВт;

· теплообменное устройство лазеров;

· теплообменное устройство фокусирующей головки;

· компрессора обдува фокусирующей головки (ФГ) лазера;

· система пожаротушения контейнера с лазерной установкой;

· система термостатирования контейнера с лазерной установкой;

· подсистема ориентации и стабилизации (ПОС) фокусирующей головки.

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

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

В рамках данного дипломного проекта были разработаны протоколы информационного взаимодействия для следующих устройств: компрессор обдува фокусирующей головки лазера, система термостатирования контейнера, система оповещения и пожаротушения (АСПТ), аппаратный модуль подсистемы ориентации и стабилизации (АМ ПОС), теплообменное устройство лазера, теплообменное устройство ФГ. Для отработки ПО информационного взаимодействия ПУ СЛК с оборудованием СЛК и было спроектировано и реализовано ПО информационного взаимодействия программных имитаторов оборудования СЛК.

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

Основные положения работы были представлены на конференции: «Конкурс молодых специалистов в области научных исследований, опытно-конструкторских работ и инновационных проектов ОАО «ЦНИИ «Курс». По результатам данной работы публикуется в статья «Разработка специального программного обеспечения пульта управления судового лазерного комплекса» в журнале «Проблемы развития корабельного вооружения и судового радиоэлектронного оборудования».



1. АНАЛИЗ ЗАДАНИЯ

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

Реализованное ПО должно быть на языке программирования высокого уровня C#, с использованием библиотек .NET Framework и работать в операционной системе Windows 7. Передача информации по сети должна осуществляется поверх протокола TCP/IP.

Поэтому, требуется изучить возможности платформы .NET Framework по передаче данных по протоколу TCP/IP. Нужно изучить основные классы и методы, которые используются при передаче данных по сети.

Так как ПО для ОКР «Ледорез-2» пишут несколько человек следует учитывать то, что данное ПО является модулем для другого ПО верхнего уровня. Реализованное ПО должно иметь понятный и описанный программный интерфейс для других программистов. Для уменьшения дублирования кода, а также для более гибкой разработки ПО следует использовать существующие паттерны программирования. Следует разработать архитектуру ПО и выбрать паттерн, который хорошо вписывается в .NET Framework.

Следует изучить протокол информационного обмена High Power Laser Monitoring (Ethernet) IPG Laser. Протокол распространяется на целую линейку лазерных устройств, с различными характеристиками и комплектующими. Поэтому, следует на основании протокола выделить основные команды, которые ПУ СЛК будет отправлять лазеру. Для первичной проверки ПО модуля информационного взаимодействия ПУ СЛК с лазером следует реализовать ПО приема команд от ПУ СЛК программным имитатором лазера. После проверки ПО ПУ СЛК на программных имитаторах следует провести его тестирование на реальном лазерном устройстве.

Для остальных устройств СЛК следует разработать протокол информационного взаимодействия. В целях унификации следует разрабатывать протоколы на основе уже полученного протокола High Power Laser Monitoring (Ethernet) IPG Laser. Унифицированные протоколы позволяют уменьшить количество программного кода и увеличить возможность его повторного использования.

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

2. ОБЗОРНО АНАЛИТИЧЕСКАЯ ЧАСТЬ

Устройства СЛК

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

Каждое устройство имеет численные параметры, которые характеризуют основные функции устройства. Для этих числовых параметров существует диапазон нормальных значений, в которых устройство должно функционировать. Устройство должно оповещать ПУ СЛК о том, что какой-то параметр вне нормального диапазона. Также, устройство должно формировать диагностическое сообщение, в котором описаны причины поломки и советы по устранению. Диагностические сообщения должны иметь текстовый формат. При таком формате сообщения на протокол не накладываются ограничения. Заполнять диагностические сообщения должны проектировщики устройств, которые хорошо осведомлены об устройстве, его внутреннем строении и о действиях, необходимых для устранения неполадок.

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

Компрессор ФГ

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

Согласно руководству пользователя, компрессор может запускаться несколько минут. Поэтому, кроме сигнала о том, что компрессор активен, требуется сигнал «компрессор запускается». Так же, в руководстве пользователя, была описана ситуация перегрева мотора. Данный сигнал также должен присутствовать в протоколе.

Описанные выше параметры можно считывать из аналоговых водоходов компрессора.

Система термостатирования контейнера

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

Основная задача оператора пульта состоит в установке нормального диапазона температур для двух ярусов и тамбура.

Основанная информация, получаемая от данной системы - это показания значения температуры с датчиков температуры. На каждом ярусе находится 5 датчиков. Кроме этой информации, следует передавать показания датчиков влажности на каждом ярусе и показания датчика наружной температуры. Если показания какого-то датчика находятся вне нормы, должна генерироваться ошибка и диагностическое сообщение.

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

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

Автоматическая система оповещения и пожаротушения (АСПТ)

Данная система предназначена для тушения пожаров, возникших в контейнере. Для обнаружения пожара система содержит два вида датчиков: датчики на тепло/огонь и датчики на задымление. В состав данной системы входит порошковая система пожаротушения. Система пожаротушения имеет аналоговый выход для дистанционной активации средств пожаротушения. Данный выход подключен к кнопке на ПУ СЛК. Поэтому реализовывать команду включения системы пожаротушения не имеет смысла.

Система пожаротушения работает в двух режимах - автоматическом и ручном. В автоматическом режиме при активации сигнала «пожар» система пожаротушения активируется автоматически. В ручном режиме оператор должен сам активировать средства пожаротушения переключением тумблера. В обоих режимах оператор может активировать средства пожаротушения переключением тумблера на ПУ.

При получении сигнала обнаружения огня или дыма от одного из датчиков, генерируется сигнал «угроза пожара». При получении сигнала от двух датчиков активируется сигнал «пожар».

Также, система АСПТ должна сообщать о неисправностях датчиков.

Аппаратный модуль подсистемы ориентации и стабилизации (АМ ПОС)

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

Так как в разных морях требуется различное расстояние от борта и расстояние до поверхности льда следует определить команду, которая будет задавать эти данные.

Основные данные АМ ПОС - это показания дальномеров. Дальномеры меряют расстояние от ФГ до поверхности льда. Кроме того, АМ ПОС должен передавать температуру ФГ, так как необходим контроль за ее перегревом. Для мониторинга стабилизации требуются показания отклонений от заданных значений.

АМ ПОС должен реализовать команды перехода из походного положения в рабочие и наоборот. В протоколе передаются сигналы переходных состояний из одного положения в другое. После перехода из походного положения в рабочее следует передать команду старта стабилизации ФГ.

Теплообменное устройство ФГ и лазера

В СЛК присутствуют два теплообменных устройства: теплообменное устройство лазера и теплообменное устройство ФГ. Их основная задача в отводе тепла от этих устройств. То есть, перед ними стоит задача охлаждения. В качестве теплоотводящей среды используются различные жидкости.Теплообменное устройство имеет два контура циркуляции охлаждающих жидкостей. Первый контур идет от ТУ к ФГ или лазеру. Его задача состоит в отводе тепла от этих устройств. Теплообменное устройство получает поток жидкости, пришедший от устройств, входной поток, охлаждает его, и снова направляет его к устройствам. Охлаждённый поток, идущий к устройствам называется выходным потоком.

Рисунок 1 - Схема походного и рабочего положения ПОС

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

Необходим контроль над температурой входного потока воды, выходного потока воды и температуры забортной воды. Если какое-то из значений находится вне нормального диапазона, то генерируется сигнал тревоги и диагностическое сообщение. Оператор должен задавать только диапазон температуру выходного потока воды. Диапазон для входного потока и диапазон нормального значения забортной воды рассчитывается ТУ.

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

Протокол High Power Laser Monitoring (Ethernet)

Данный протокол используется для наблюдения за состоянием серии лазеров фирмы IPG Laser. Протокол не предусматривает «быстрое» взаимодействие с лазером. Но в данной работе это не важно, так как основное требование к ПУ СЛК - это задать мощность излучения и включить излучение.

Параметры информационного взаимодействия с лазером следующие:

1. Лазер только отвечает на команды;

2. Для передачи данных используется протокол TCP/IP v4;

3. Максимальное число активных соединений: 1;

4. Данные передаются в бинарном формате. Параметры, состоящие из более чем одного байта, передаются в формате little-endian (Intel).

ПУ СЛК или другое устройство формирует пакет, который содержит код команды, служебную информацию и, если это необходимо, данные. Затем лазер формирует ответный пакет на полученный запрос.

В протоколе команды можно разделить на две большие группы:

1. Команды мониторинга;

2. Команды управления.

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

Команды протокола High Power Laser Monitoring (Ethernet) IPG Laser представляют собой обычные структуры. Каждую структуру можно разделить на заголовок и данные. В заголовке содержится служебная информация о том, как следует интерпретировать данные. Наиболее важная часть информации в заголовке это: номер команды, размер данных и контрольная сумма. Данные в этом пакете - это сериалзованные структуры. Здесь под сериализацией имеется ввиду перевод структуры в массив байт.

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

Платформа .NET Framework

Платформа .NET Framework - это программная платформа, разработанная корпорацией Microsoft для широкого круга задач. .NET Framework базируется на базовой библиотеке классов BCL (Base Class Library), в которой описаны основные типы данных, и среду выполнения Common Language Runtime (CLR).

Компиляторы, написанные для платформы .NET Framework, компилируют исходный код не в машинный код целевой платформы, а в промежуточный язык Common Intermediate Language (CIL). CIL - это промежуточный язык платформы .NET Framework. Благодаря компиляции в промежуточный язык скомпилированную программу можно запускать на различных аппаратных платформах. Нужно только что бы на этой аппаратной платформе была реализованная .NET Framework. CIL для платформы .NET Framework можно сравнить с байт-кодом для Java Virtual Machine [1].

После написания программы на одном из поддерживаемых языков программирования происходит его компиляция в промежуточный язык CIL. Полученный результат в терминологии .NET Framework называется сборкой или assembly. Затем, при запуске программы, вызывается CLR которая использует JIT (Just In Time) компилятор и компилирует программу машинный код целевой платформы. Происходит так называемая компиляция «на лету». Современные JIT-компиляторы обладают высокой скоростью и позволяют достигнуть высокой степени быстродействия [2]. После запуска программы CLR продолжает работать. В ее задачу входит контроль за исполнением, автоматический контроль за памятью, управление потоками выполнения, соблюдение правил безопасности и многое другое. Код, который выполняется под контролем CLR называется управляемым. Соответственно, код выполняемый вне CLR называется неуправляемым.

Кроме BCL, в которой находятся базовое классы, .NET Framework также имеет библиотеку Framework Class Library (FCL). В FCL входят различные классы и технологии. Некоторые из этих технологий перечислены ниже [3]:

1. Технология Windows Forms. Данная технология предназначена создания пользовательского интерфейса и оконных приложений;

2. Технология ADO.NET. Данная технология является реализации технологии доступа к базам данных по технологии ADO для платформы .NET Framework;

3. Технология ASP.NET. Данная технология предназначена для создания активных серверных страниц и web-программирования в целом;

4. Технология Language Integrated Query (LINQ), предназначенная для доступа к коллегиям данных, на языке схожем с SQL;

5. Технология Windows Presentation Foundation (WPF), предназначенная для создания графического интерфейса пользователя нового поколения;

6. Технология Windows Communication Foundation (WCF). Данная технология используется для связи различный приложений по сети.

Как таковая, платформа .NET Framework во многом схожа с другой программной платформой от компании Oracle - Java. Главное отличие состоит в том, что Java создавался как язык для встроенных систем и интернета. Поэтому, в Java Virtual Machine были заложены ограничения, которые присущи реальным аппаратным платформам. .NET разрабатывалась же как абстрактная система.

Базовая часть платформы .NET Framework стандартизирована международной ассоциацией ECMA. Таким образом, Microsoft поощряет создания других реализаций платформы.

Следует уточнить, что версия платформы, используемая в данной работе, является платформой .NET Framework реализованная компанией Microsoft.

Для реализации передачи данных по протоколу TCP в платформе .NET Framework присутствует класс TcpListener [4]. Данный класс предоставляет простые блокирующие методы для ожидания подключения клиента. То есть, вызвав функцию AcceptTcpClient или AcceptSocket данный поток выполнения блокируется до тех пор, пока объекты класса TcpClient и Socket не подключаться. Конструктор данного класса принимает IP-адрес и порт, который следует прослушивать [5].

После создания объекта данного класса вызывается метод Start. После вызова этого метода, все подключенные клиенты буду вставать в очередь подключения. Количество клиентов регламентируется свойством MaxConnections. После вызова метода Stop объект прекращает заполнять очередь подключений и отвергает все подключения. Для получения подключения, как уже упоминалось, используются блокирующие методы AcceptSocket, для получения объекта Socket, или AcceptTcpClient для получения объекта TcpClient. Метод Pending сообщает, если в очереди активное подключение.

Класс TcpListener является пассивным. То есть он только ожидает соединения, сам он его инициализировать не может. Для инициализации соединения в платформе .NET Framework присутствует класс TcpClient.

Данный класс, также как и TcpListener, реализует блокирующие методы передачи данных по сети. При создании объекта данного класса в качестве параметров конструктору указываются IP-адрес и порт конечного подключения. В отличии от класса TcpListener при неудачной попытке произвести соединение объект генерирует исключение. Данный класс способен подключаться к любому объекту, созданному с использованием протокола ProtocolType TPC [6].

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

Данный объект не способен передавать другие объекты или структуры. Для их передачи их необходимо сериализовать [7].

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

В платформе .NET Framework сериализуемые классы должны быть помечены атрибутом SerializableAttribute [8]. Атрибут - это специальный тип данных, который входит в метаданные, то есть, описание класса. Метаданные используются CLR и программистом при использовании рефлексии. При попытке сериализации объекта, не помеченного данным атрибутом, генерируется исключение SerializationException.

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

Если объект имеет ссылки на другие объекты, то они будут сериалзованы только в том случае, если они отмечены атрибутом SerializableAttribute.

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

При десериализации потока байт вызывается конструктор по умолчанию. Если у объекта отсутствует открытый конструктор по умолчанию, то генерируется исключение.

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

В платформе .NET Framework присутствует класс, который способен превращать базовые типы данный в байтовый массив. Данный класс называется BitConverter.

Данный класс имеет минус. Формат следования байтов, то есть little-endian или big-endian, зависит от конкретной платформы. Поэтому при передаче данных по сети в протоколе должно быть оговорено, в каком формате следования битов передаются данные. Данный класс имеет свойство IsLittleEndian который показывает используется ли формат little-endian на данной машине [9].

При использовании класса BitConverter следует использовать следующий алгоритм:

1. Создать байтовый массив необходимого размера;

2. Сериализовать поле или свойство объекта;

3. Если формат следования байтов не такой, какой используется в протоколе, перевернуть полученный массив байт;

4. Записать полученный после сериализации данные в байтовый массив с соответствующим сдвигом;

5. Перейти к следующему полю или свойству.

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

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

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

StructLayout принимает в качестве параметра перечисление LayoutKind. Данное перечисления имеет следующие значения:

1. Sequential - при этом значении перечисления поля в памяти располагаются последовательно;

2. Auto - компилятор сам определяет расположение полей в памяти;

3. Explicit - программист сам управляет размещением памяти с помощью атрибута FieldOffset. Атрибут принимает значение, на которое компилятор сдвигает данное поле в памяти.

Также в атрибут StructLayout можно передать параметр Pack=n, где n - это число байт, по которому будет происходить выравнивание.

Для данной работы можно использовать два способа размещения. Первый - это использовать LayoutKind.Sequential и Pack=1. Таким образом поля будут располагаться последовательно и без пропусков. Именно таким образом устроено большинство структур, объявленных в Windows API и C/C++.

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

Архитектура ПО

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

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

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



Рисунок 2 - Схема взаимодействия модуля передачи данных

Блок приема/передачи TCP/IP пакета отвечает за:

· контроль состояния соединения;

· формирование TCP/IP пакета;

· извлечение пакета информационного взаимодействия из TCP/IP пакета;

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

Блок приема/передачи пакета протокола информационного взаимодействия отвечает за:

· подсчет и проверку контрольных сумм;

· извлечение форматированных данных из пакета;

· формирование пакета протокола информационного взаимодействия;

· предпроверку форматированных данных.

Блок форматирования и обработки данных отвечает за:

· проверку значений полученных данных;

· преобразование данных из полученных от устройств СЛК структур данных;

· создание структур команд;

Данная схеме не является архитектурой ПО. Это лишь группирование функционала.

ПУ СЛК будет соединен с несколькими устройствами. Каждое это устройство будет иметь свой собственный IP-адрес. То есть, для каждого устройства будет создано свое TCP соединение. Для поддержания TCP соединения следует использовать класс TcpClient платформы .NET Framework. Данный класс является блоком приема/передачи TCP/IP пакета.

Протоколы информационного взаимодействия основаны на High Power Laser Monitoring (Ethernet) IPG Laser. В данном проколе, как уже было упомянуто, пакет можно разделить на заголовок и данные. Разработанные протоколы имеют такую же структуру. Данные помещаются в пакет с заголовком (служебной информацией). Так как заголовок для всех пакетов в разработанных протоколах информационного взаимодействия является одинаковым, его обработку можно вынести в отдельный блок. Данную функцию можно вынести в один класс - TCPClient (не путать с TcpClient). Данный класс реализует функционал блока приема/передачи пакета протокола информационного взаимодействия.

Для каждого устройства были написаны отдельные классы-контейнеры [11]. Данные классы используются для визуализации информации. Эти классы построены на основании протоколов информационного взаимодействия. В обязанность данных классов также входит преобразование структур, полученных от устройств СЛК и передача управляющих структур в устройства. Данный класс реализует блок форматирования и обработки данных.

При таком разбиении следует реализовать один класс TCPClient и связать его с классом TcpClient. Затем, данный класс должен как-то обмениваться информацией с контейнерами, для реализаций команд протокола информационного взаимодействия.

При такой взаимосвязи можно использовать следующие паттерны: стратегия или шаблонный метод [13].

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

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

Блок приема/передачи пакета протокола информационного взаимодействия больше подходит под паттерн стратегия. Но вместо того, чтобы создавать новые классы, для реализации команд, можно поступить иначе. Язык C# и платформа .NET Framework позволяет передавать делегаты - объектно-ориентированные указатели на функции [12]. Таким образом, метод обработки пришедших данных задается из вне. Кроме обработки пришедших данных, также передается метод сериализации объекта, который нужно передать. По умолчанию используется маршелизация, но, если этот подход по каким-то причинам использовать нельзя передается метод, который производит бинарную сериализацию объекта. Методы, которыми должны обрабатываться данные или же сериализоватся данные находятся в блоке формирования и обработки данных.

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

Архитектура модуля информационного взаимодействия программных имитаторов схожа с архитектурой модуля информационного взаимодействия ПУ СЛК.

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

В качестве блока приема/передачи TCP пакета реализован класс TCPServer. Данный класс использует возможности класса TсpListener по приему и обработки TCP пакетов. Далее, полученная информация передается обработчику пакета информационного взаимодействия. После этого, на основании номера команды, данные передаются в обработчик команды. При такой взаимосвязи можно использовать следующие паттерны стратегия, шаблонный метод наблюдатель и цепочка обязанностей[12]. Первые два паттерна объяснялись выше.

Паттерн наблюдатель предполагает создание класса «издателя». Этот класс, данном случае это TCPClient, оповещает подписчиков-потребителей о том, что он готов передать им данные. Подписчиками являются команды.

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

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

Взаимодействие между блоками в программных имитаторах, также, осуществлена с помощью делегатов. Класс TCPServer прочитав байтовый массив из TCP соединения передает их делегату-обработчику. Данный обработчик извлекает служебную информацию из заголовка, анализирует и проверяет ее, и по номеру команды находит исполнителя команды. Исполнитель команды выполняет действие, затем возвращает данные. На основании данных формируется ответный-пакет информационного взаимодействия, который сериализуется и отправляется классом TCPServer на ПУ СЛК.

3. СПЕЦИАЛЬНАЯ ЧАСТЬ

На основании изученного протокола High Power Laser Monitoring (Ethernet) IPG Laser был разработан протокол информационного взаимодействия ПУ с оборудованием СЛК.

Ниже представлено описание протокола.

1. Для передачи данных используется протокол TCP/IP v4.

2. Максимальное число активных соединений: 1

3. Данные передаются в бинарном формате. Параметры, состоящие из более одного байта передаются в формате little-endian (Intel).

4. Каждому устройству назначается порт по умолчанию. Порты должны быть уникальные.

5. Каждому устройству назначается IP-адрес по умолчанию.

6. Для кодирования строковых значений используется кодировка Windows-1251.

7. В протоколе все «сдвиги» и «размеры» приведены в байтах.

8. По умолчанию, если в течении 5 секунд не пульт не посылает пакет, устройство разрывает соединение.

9. В протоколе используются следующие обозначения типов данных:

a. Byte - 8 бит, беззнаковое целое число

b. Ushort - 16 бит, беззнаковое целое число

c. Ulong - 32 бит, беззнаковое целое число

d. String[N] - Массив из N символов строки в кодировке Windows-1251

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

Формат команды запроса

Формат команды запроса представлен в таблице 1.

Таблица 1 Формат команды запроса

Сдвиг	Размер	Тип	Название поля	Описание
0	2	Ushort	Command	Код команды
2	2	Ushort	Reserved	Должен быть нулевой
4	4	Ulong	Data size	Размер данных команды
8…(N+8)	N		Data	Данные
N+8	2	Ushort	Crc16	Контрольная сумма CRC16 (байты 0...N+8-1)

Подробное описание полей представлено ниже:

1. Command - код команды. Данное поле задает номер команды, которое устройство должно выполнить. На основании номера команды устройство интерпретирует данные и составляет данные для ответа;

2. Reserved - неиспользуемое поле. Это поле нужно для того, чтобы заголовок формата ответа был одинаков по полям и размеру с командой ответа. При таком сходстве облегчается программирование обработки команды запроса устройством;

3. Data size - размер данных. Так как размер данных динамичен, то следует указать сколько данных требуется прочитать. Для команд, которые не передают данные данное поле равно 0;

4. Data - данные. В этом поле ПУ передает некие данные устройству. Формат данных зависит от поля Command. Для команд, которые не передают данные данное поле не заполняется;

5. Crc16 -16-битный циклический избыточный код. ПО ПУ СЛК вычисляет 16-битный циклический избыточный код пакета и записывает его в это поле. Затем устройство на основании полученного пакета вычисляет 16-битный циклический избыточный код пакета и сравнивает его с этим полем. Если значения не равны, то пакет отбрасывается.

Формат команды ответа

Формат команды ответа представлен в таблице 2.

Таблица 2 Формат команды ответа

Сдвиг	Размер	Тип	Название поля	Описание
0	2	Ushort	Answer	Код ответа (код пришедшей команды)
2	2	Ushort	Execution code	Код выполнения операции (Таблица 3)
4	4	Ulong	Data size	Размер данных ответа (N)
8...(N+8)	N		Data	Данные ответа
N+8	2	Ushort	Crc16	Контрольная сумма CRC16 (байты 0...N+8-1)

Команда ответа посылается устройством на ПУ в ответ на команду запроса. Подробное описание полей представлено ниже:

1. Answer - код ответа. Данное поле равно полю Command пришедшей команды запроса;

2. Execution code - Код выполнения операции. Этот код показывает, чем закончился анализ команды запроса и данных в них, а также, состояния выполнения команды. Значения, которые может принимать Execution code и их краткое описание дается в таблице 3.

3. Data size - размер данных. Так как размер данных динамичен, то следует указать сколько данных требуется прочитать. Для команд, которые не передают данные данное поле равно 0.

4. Data - данные. В этом поле устройство передает некие данные ПУ. Формат данных зависит от поля Answer. Для команд, которые не передают данные данное поле не заполняется.

5. Crc16 -16-битный циклический избыточный код. ПУ вычисляет 16-битный циклический избыточный код и сравнивает его с полем в команде ответа. Если поля не равны, то пакет отбрасывается.

Таблица 3 Код выполнения операции

Код (Беззнаковый)	Код (Знаковый)	Код (HEX)	Описание
0	0	0	Команда выполнилась успешно
2	-1	0xFFFF	Неизвестная команда
65532	-4	0xFFFC	Команда не выполнилась, так как параметр вне дозволенного диапазона
65529	-7	0xFFF9	Команда не может быть выполнена сейчас
65528	-8	0xFFF8	Неверная контрольная сумма

Подробное описание кода операции представлена ниже:

1. Команда выполнилась успешно - данный код показывает то, что команда запроса была обработана успешно. Данные не были искажены. Устройство завершило все действия, которые требовалось выполнить согласно принятому коду команды. А также данные, которые требуется передать согласно принятому коду команды были упакованы в пакет.

2. Неизвестная команда - данный код показывает то, что ПУ в поле Command указал команду, которой нет в протоколе для данного устройства.

3. Команда не выполнилась, так как параметр вне дозволенного диапазона - данный код показывает, что одно или несколько значений которые передаются в поле Data вне дозволенного диапазона. Например, в протоколе микроклимата командой SetTemperatureRange задается температурный диапазон. Если температурный диапазон слишком высокий или слишком низкий и не может быть задан устройству, то возвращается данный код.

4. Команда не может быть выполнена сейчас - данный код показывает, что команда, переданная полем Command, не выполнилась. Команда может быть не выполнена по разным причинам. Причиной может стать внутренние состояние устройства, например, перегрев. Или же не были выполнены условия, для выполнения команды.

5. Неверная контрольная сумма - код означает что, вычисленное устройством 16-битный циклический избыточный код и не равен полю Crc16 в команде запроса. Команда не выполняется, данные не передаются.

В данной работе команды будут описываться таблицей, представленной ниже.

Таблица 4 Описание команд

Команда	В данной строке будет буквенное обозначение команды
Описание	В данной строке будет написано предназначение команды и ее описание
Код	Число, которое записывается в поле Command команды запроса или в поле Answer команды ответа
Размер данных	Число, которое записывается в поле Data size команды запроса
Данные	Структура данных, которая сериализуется и записывается в поле Data команды запроса
Размер ответных данных	Число, которое записывается в поле Data size команды ответа
Ответные данные	Структура данных, которая сериализуется и записывается в поле Data команды ответа

Общие команды и структуры данных устройств

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

Команда SetIpSettings

Команда SetIpSettings используется для изменение сетевых настроек устройства. После передачи данной команды соединение между устройством и СЛК разрывается. Данная команда отсутствует в протоколе информационного взаимодействия с аппаратным модулем подсистемы ориентации и стабилизации (АМ ПОС).

Таблица 5 Формат команды SetIpSettings

Команда	SetIpSettings
Описание	Изменение сетевых настроек устройства
Код	2
Размер данных	Размер структуры IpSettings
Данные	Структура IpSettings
Размер ответных данных	0
Ответные данные	-

В протоколе используется следующий формат структуры IpSettings.

Таблица 6 Формат структуры IpSettings

Сдвиг	Размер	Название поля	Размерность	Тип	Описание
0	4			Ulong	Должно быть равно 0
4	4	IP Address		Ulong	Новый IP адрес
8	4	IP Mask		Ulong	Новая маска подсети
12	4	Default Gateway		Ulong	Новый шлюз по умолчанию
16	2	Port		Ushort	Новый порт

Если поле IP address, IP Mask, Default Gateway или Port равно 0, то параметр сетевой настройки меняться не будет.

Команда GetDiagnosticMessages

Данная команда посылается для получения диагностического сообщения.

Таблица 7 Формат команды GetDiagnosticMessages

Команда	GetDiagnosticMessages
Описание	Получить диагностические данные
Код	5
Размер данных	0
Данные	-
Размер ответных данных	Размер структуры Diagnostic Messages
Ответные данные	Структура Diagnostic Messages

В протоколе используется следующий формат структуры Diagnostic Messages

Таблица 8 Формат структуры Diagnostic Messages

Сдвиг	Размер	Название поля	Размерность	Тип	Описание
0	2	Size Of Diagnostic Message		Ushort	Размер диагностического сообщения (N)
2	2	Size Of Advice Message		Ushort	Размер сообщения с рекомендацией (M)
4	N	Diagnostic Message		String[N]	Диагностическое сообщение, описывающее ошибки и неисправности
4 + N	M	Advice Message		String[M]	Сообщение с рекомендацией по устранению неисправностей

Если необходимо записать несколько диагностических сообщений или рекомендаций по устранению, то каждое сообщение разделяется символом новой строки ('\n', код символа: 10).

Протокол не устанавливает, что именно необходимо записать в поля Diagnostic Message и Advice Message для конкретного устройства. Данные в этих полях определяются разработчиками устройств. Данное решение было принято в связи с тем, что количество неисправностей и рекомендации по их устранению наилучшим образом известны разработчикам устройств. И так как данные передаются в текстовом форманте ПО ПУ СЛК может вывести на экран диагностическое сообщение и сообщение с рекомендацией без какой-либо обработки.

Формат команды и структур данных информационного обмена с компрессором обдува ФГ

Команда GetCompressorData

Таблица 9 Формат команды GetCompressorData

Команда	GetCompressorData
Описание	Получить данные от компрессора
Код	4
Размер данных	0
Данные	-
Размер ответных данных	Размер структуры Compressor Data
Ответные данные	Структура Compressor Data

В протоколе используется следующий формат структуры Compressor Data

Таблица 10 Формат структуры CompressorData

Сдвиг	Размер	Название поля	Размерность	Тип	Описание
0	2	Current Voltage	0.1 В	Ushort	Текущее напряжение поданное на компрессор
2	2	Current Pressure	0.1 Бар	Ushort	Давление воздуха на выходе компрессора
4	2	Current Temperature	0.1 C	Ushort	Температура воздуха на выходе компрессора
Продолжение таблицы 10
Сдвиг	Размер	Название поля	Размерность	Тип	Описание
6	2	Current Humidity	0.1 %	Ushort	Влажность воздуха на выходе компрессора
8	1	Status		Byte	Текущее состояние компрессора (См. Таблицу 11)
9	1	Error		Byte	Ошибки (См. Таблица 12)

Таблица 11: Значение битов в поле «Status»

Бит	Маска	Описание
0	0x00000001	Питание подключено
1	0x00000002	Компрессор запускается
2	0x00000004	Компрессор активен
3	0x00000008	Присутствуют не переданные диагностические данные
4	0x00000010	Зарезервировано
5	0x00000020	Зарезервировано
6	0x00000040	Зарезервировано
7	0x00000080	Зарезервировано

Подробное описание значений битов представлено ниже:

1. Питание подключено - данный бит равен 1 когда на компрессор обдува ФГ подается питание. Устройство с которым общается ПУ может иметь независимое питание. Поэтому установка соединения не является показателем того, что на компрессор подано питание;

2. Компрессор запускается - бит равен 1 показывается что на компрессор было подано питание, и он запускается. После того как бит «Компрессор активен» становится равен 1 данный бит должен быть 0;

3. Компрессор активен - активность данного бита показывает, что компрессор активен и не имеет ошибок;

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

Таблица 12: Значение битов в поле «Error»

Бит	Маска	Описание
0	0x00000001	Ошибка включения устройства
1	0x00000002	Давление воздуха вне нормального значения
2	0x00000004	Температура воздуха на выходе вне нормального значения
3	0x00000008	Влажность воздуха вне нормального значения
4	0x00000010	Перегрузка мотора
5	0x00000020	Общая ошибка
6	0x00000040	Зарезервировано
7	0x00000080	Зарезервировано

При активности бита данном поле должно генерироваться диагностическое сообщение и бит «Присутствуют не переданные диагностические данные» в поле Status должен установится в 1. Подробное описание значений битов представлено ниже:

1. Ошибка включения устройства - данный бит равен единице, если после подачи питания на устройства не удалось его запустить. Следует проверить сбойный файл, где будет указаны причины и методы устранения данной проблемы;

2. Давление воздуха вне нормального значения - активность данного бита показывает, что давление воздуха на выходе компрессора ниже или выше нормального значения. Диапазон значений задается проектировщиками компрессора. Бит автоматически обнуляется, когда значение давления воздуха на выходе входит в диапазон нормальных значений;

3. Температура воздуха вне нормального значения - активность данного бита показывает, что температура воздуха на выходе компрес...