СИНТЕЗ ПРОТОКОЛА АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ И КОНТРОЛЯ ГЕТЕРОГЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ УСТРОЙСТВ

УДК 37.035
AUTOMATIC MANAGEMENT AND CONTROL FOR
HETEROGENIC TELECOMMUNICATION DEVICES PROTOCOL SYNTHESIS
Kruchinin Sergei Vladimirovich, candidate of political sciences, chief research scientist, “Wellborn” Llc., Voronezh, siblis@yandex.ru
Zotov Sergei Valerievich, engineer, JSC “Concern “Sozvezdie”, Voronezh,
wildlynx@mail.ru
Abstract. The article researches the problem of automatic management and control of heterogenic devices protocol synthesis. The authors propose the protocol synthesis methodology basing on the math model. Protocol can be used for automatic control and managing of heterogenic devices universally. Achieved results can be used for network organization and development, for VANET, MANET and other special networks. It can be useful for network CADD, SCADA development and software design.
Keywords: VANET, MANET, graphs, math model, CAD, CADD, SCADA.
СИНТЕЗ ПРОТОКОЛА АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ И КОНТРОЛЯ ГЕТЕРОГЕННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ УСТРОЙСТВ
Кручинин Сергей Владимирович, кандидат политических наук, главный научный сотрудник, ООО «ВЭЛБОРН», г. Воронеж, siblis@yandex.ru
Зотов Сергей Валерьевич, инженер, ОАО «Концерн «Созвездие» (в составе
ГК «Ростехнологии», бывший Воронежский научно-исследовательский институт связи), г. Воронеж, wildlynx@mail.ru
Аннотация. В статье рассматривается проблема синтеза протокола автоматизированного контроля и управления гетерогенными телекоммуникационными устройствами. На основе разработанной авторами математической модели предлагается методология построения протокола, позволяющего единообразно опрашивать и управлять разнородными устройствами. Полученные результаты могут быть использованы для организации работы сенсорных сетей, телекоммуникационных сетей VANET и MANET, а также стандартных телекоммуникационных сетей. Также представляет интерес в разработке САПР, АСУ, работающих в сфере систем связи, и собственно в разработке программного и аппаратного обеспечения систем связи.
Ключевые слова: АСУ, САПР, телекоммуникационный протокол, телекоммуникационные устройства, сенсорные сети, VANET, MANET, графы, математическая модель, теория множеств.
Актуальность. В настоящее время существует большое разнообразие телекоммуникационных устройств. Но, благодаря существованию общепризнанных стандартов (RFC, IEEE), телекоммуникационных протоколов, независимые производители выпускают совместимое оборудование и программное обеспечение.
Хуже обстоит ситуация с перспективными и специализированными устройствами. Тем не менее, научно-технический прогресс показывает новые отрасли применения. Среди современных достижений научно-технического прогресса можно назвать: частная аэрокосмическая отрасль (Virgin Galactic с кораблями Space Ship Two [1]), роботы c адаптивным управлением, например получивший известность изготовленный для DARPA компанией Boston Dynamics робот Big Dog [2] проекты по созданию беспилотных автомобилей [3; 4], проект по созданию обитаемой колонии на Марсе Mars One [5]. Все эти проекты требуют построения телекоммуникационных сетей, автономных или значительно отличающихся от сети Интернет. В зарубежной научной литературе широко представлены материалы, посвященные исследованиям в области построения VANET [6-9] и сенсорных сетей [10; 11].
И если в отечественной науке интерес к сенсорным сетям наблюдается (см. например, [12]), то проблематика VANET практически не представлена. Одной из первых попыток представить VANET для отечественной науке была представлена автором в [13].
Проблема практической реализации интеграции разнородного оборудования была неоднократно рассмотрена автором. Так мы касались разработки САПР для построения сети используя гетерогенное оборудование (см. например [15; 16]), вопросы конфигурации сети в процессе работы (напр. [17]), тестирования работы сети [18;19], построенной с использованием гетерогенного оборудования. Одной из важных задач обслуживания гетерогенных сетей стала задача контроля и управления гетерогенными устройствами, для чего были разработаны соответствующее программное [20] и аппаратное обеспечение [21; 22].
Обобщением опыта стала разработка математической модели, позволяющей описать свойства и взаимодействия гетерогенных телекоммуникационных устройств для возможности однотипного взаимодействия между ними, а также с программным обеспечением. Подобная модель позволила бы обобщить опыт разработки САПР гетерогенных сетей, АСУ гетерогенных сетей, организации сети и маршрутизации на разных уровнях сетевой модели ЭМВОС и стека протоколов TCP/IP.
Отметим, что зачастую разработка телекоммуникационных протоколов для экспериментальных и узкоспециализированных сетей, особенно в отечественной практике, носит характер инженерный, интуитивный, без разработки математической модели и теоретического обоснования. Мы попытаемся разработать подход по
синтезу протокола с разработкой математической модели и ее применением.
Цель исследования - продолжить разработку математической модели [23], построив на ее основе протокол управления и контроля гетерогенными телекоммуникационными сетями для использования в серверном и клиентском программном обеспечении устройств.
Термины и сокращения.
АТКС - автономная телекоммуникационная сеть. Внутренняя локальная сеть транспортного средства в случае мобильных сетей транспортных средств/УЛКЕТ [13].
ТКУ - телекоммуникационное устройство (устройство, обла-дащее возможностью подключения к АТКС.
ТКМС - телекоммуникационный модуль сопряжения [21 ;22].
САУКТ - сервер автоматизированного управления и контроля телекоммуникационными устройствами (ТКУ), собирает информацию от КАУКТ.
АСАУКТ - агрегирующий сервер автоматизированного управления и контроля телекоммуникационными устройствами (ТКУ), собирает информацию от других КАУКТ и САУКТ.
КАУКТ - клиент автоматизированного управления и контроля телекоммуникационными устройствами (может быть реализован для микроконтроллера ТКУ).
ТАУКТ - терминал автоматизированного управления и контроля телекоммуникационными устройствами (в виде ЭВМ или специализированного терминала).
Организация исследования. В [23] мы рассмотрели наборы типов устройств 8={81,82....8п}, каждому из которых можно сопоставить множество типов состояний 8;={б1,82,83 ... .Бп}, каждый из типов состояний, в свою очередь, сопоставляется с набором значений этого типа состояния. Например для б1=1 (тип устройства) набор состояний 811={1,2,3...п} - набор порядковых номеров типов устройств. Мы также показали, что в случае конечных наборов можно свести все устройства к одному набору типов состояний, снабдив каждый из наборов состояний дополнительным элементом «не применимо» - состояние 0.
Некоторые из этих типов состояний должны быть определены заранее при разработке протокола. Это тип устройства и система адресации. Остальные состояния могут определяться уже в ПО, использующем протокол, нужно только поддерживать единый перечень типов состояний.
Нас будут интересовать следующие состояния: тип ТКУ, идентификатор ТКУ в сети, адреса (1Р-адрес, МАС-адрес, внутренний адрес), доступность устройства, доступность устройства другому устройству. Также мы рассмотрим возможность настройки оповещения по таймеру, таким образом, наличие такой конфигурации в КАУКТ устройства также является конфигурацией - снабжая новыми типами состояний - период опроса. Заметим, что состояния могут меняться, т.е. каждому устройству в определенный момент времени может соответствовать одно значение данного состояния, а в другой - иное. К таким типам состояний можно отнести состояние доступности устройства, или адрес в сети. Другие состояния можно назвать условно неизменными. Например, тип устройства і, или состояние 0 (неприменимость данного запроса). Условно неизменными их мы обозначим, потому что все же ТКУ может быть заменено на ТКУ другого типа, с несколько отличающимися параметрами.
Теперь рассмотрим взаимодействия устройств. Будем считать, что устройства обмениваются состояниями, по запросу типа состояния запрашиваемое устройство возвращает запросившему значение типа этого состояния, которое ему в данный момент соответствует.
Рассмотрим одноранговый опрос устройств (например, опрашиваемое устройство находится в той же подсети, что и сервер, и опрашивается им непосредственно, см. рис. 1). САУКТ непосредственно опрашивает подчиненные ТКУ: КАКУТ передает в САУКТ информацию обо всех запрошенных состояниях (по запросу, или по таймеру).
Рис 1. Одноранговый опрос устройств
В ряде случаев предусматривается двухранговый опрос устройств (опрос устройства, являющегося абонентом непосредственно доступного устройства).
При этом САУКТ другой АТКС не задействован, опрашивается именно возможность связи непосредственно контролируемого устройства с другим устройством, используя каналы связи, связывающие эти устройства, без привлечения сервисов ТКМС (см. рис. 2). К двухранговому опросу относятся методики опроса, изложенные в [18; 19].
Обратим внимание на то, что двухранговый опрос не предназначен для сбора информации о состоянии ТКУ другой АТКС. Двуранговый опрос дает только информацию о работе каналов связи ТКУ совместно с парным ему ТКУ другой АТКС.
Рис 2. Двухранговый опрос устройств.
Но возможна и более сложная реализация. Когда обмен идет между несколькими АТКС, при этом АСАУКТ выполняет роль агрегирующего сервера, и собирает данные от САУКТ. Порядок сбора информации должен быть задан на этапе проектирования сети, например с использование САПР сети [16] с использованием графического интерфейса [24; 25] для построения карты сети и указания иерархии опроса.
Возможно также построение системы без выделения отдельных АСАУКТ и САУКТ: каждый САУКТ является и агрегирующим. АСАУКТ обмениваются информацией через ТКМС [21; 22], более того, программное обеспечение АСАУКТ может входить в состав программно-аппаратного комплекса ТКМС, такой вариант и показан на рис. 3.
Для этого, сервер САУКТ соответствующего АТКС собирает информацию о ТКУ и передает ее агрегирующему серверу (АСАУКТ), который и сообщает информацию модулю сбора информации ТАУКТ, собирающего информацию о состояниях с других АТКС и агрегирует ее в обобщенные наборы состояний (например, набор состояний не для отдельного ТКУ, а целиком для АТКС, такие как доступность, маска подсети). Отметим, что в таком случае агрегации набор типов устройств 8 надо расширять до набора типов опрашиваемых объектов 8’=8и^ где N - набор типов (конфигураций) АТКС.
Рис 3. Структура сбора информации о сети.
В работе [15] мы обосновывали возможность создания и описания типов-шаблонов АТКС, а средства [24;25] позволяют их 60
визуализировать, причем [24] на уровне графических примитивов, а [25] уже различные классы АТКС и ТКУ. Непосредственный же контроль ТКУ другого АТКС (в рамках вышеописанного двухуровнего опроса) необходим только для контроля связи, а не для непосредственного дистанционного контроля конкретным устройством другого АТКС.
Для мониторинга сети оператором служит ТАУКТ, который может быть реализован на основе ЭВМ или планшетного компьютера с использованием программного обеспечения, реализующего рассматриваемый нами протокол и графический интерфейс, например, с помощью библиотек [24; 25].
Описание протокола.
На основе вышеперечисленных рассуждений мы можем построить протокол, для использования в САУКТ и КАУКТ. Если подразумевается передачи информации от САУКТ к АСАУКТ, САУКТ также должен иметь реализацию клиентской части протокола, как КАУКТ. Реализация серверной части протокола необходима и в ТАУКТ, помимо реализации и графической части [15; 24; 25]
Структура пакета приведена в таблице 1.
Т аблица 1. Структура пакета
Заголовок 14 байт
Идентификатор протокола 1 байт
Версия протокола 1 байт
Модификация версии 1 байт
Резерв 1 байт
Длина заголовка 1 байт
Очередь идентификатора 1 байт
Идентификатор заголовка 4 байта
Количество данных в байтах 2 байта
Резерв 2 байта
Блок данных 0 - Ь байт
Контрольная сумма 1 байт
Порядок байт сетевой.
Идентификатор протокола: 0хС5 Текущая версия протокола: 0x01 Текущая модификация протокола: 0x06.
Длина заголовка: 0х0е (длина заголовка в байтах текущей версии протокола).
Контрольная сумма считается сложением всех байт данных без переноса (блок данных)
Кодировка текстовых сообщений: коі-8г
Очередь идентификаторов обозначает номер очереди, в которой нумеруются идентификаторы сообщений. В каждой очереди идентификатора нумерация с нуля, которая автоинкрементом увеличивается на единицу при посылке каждого нового пакета. При сборке ответа каждый сервер САУКТ указывает очередь и идентификатор того пакета, в ответ на которой формируется пакет. При этом выдерживаются следующие правила: если ответ происходит в ответ на запрос состояния, указывается очередь и идентификатор пакета-запроса. Если ответ происходит по таймеру опроса, указывается очередь и идентификатор пакета-запроса, выполнившего установку контроля по таймеру. Для каждого класса запроса рекомендуется вести свою очередь, но выполнение данного правила возлагается на клиент.
Структура блока данных пакета см. таблица 2.
Таблица 2. Структура блока данных пакета
№ в поле «Блок данных» Наименование Длина
1 Т ип пакета 1 байт
2 Класс запроса/ответа 1 байт
4 Тип запроса/ответа 1 байт
5 Т ип адреса 1 байт
В зависимости от значения поля «Тип пакета» заголовка пакета используются следующие типы пакетов (таблица 3).
Т аблица 3. Перечень типов пакета
Т ип пакета Описание Направление обмена
0x00 Запрос Сервер <= Клиент
0x01 Ответ Сервер => Клиент
Поле «класс запроса/ответа» может иметь несколько значений, в зависимости от типа пакета (см. таблица 4).
Таблица 4. Значения поля «класс запроса»
Класс запроса/ответа Описание
Запрос Ответ
0x01 Запрос спросить состояние устройства Ответить о состоянии устройства (сразу же)
0x02 Установить период опроса устройств Ответ о состоянии устройств по периоду
0x04 Запросить период опроса Ответить период опроса
0x05 Команда в родной последовательности устройства Результат выполнения команды (ответ от устройства)
Поле «тип адреса» также может иметь несколько значений см. таблица 5.
Таблица 5. Значения поля «тип адреса»
Т ип адреса Описание Длина адреса
0x00 Резерв 0
0x01 Идентификатор Т С (порядковый номер) 1 байта
0x02 Резерв 4 байта
0x05 1Р-адрес 4 байта
0x09 МАС-адрес 6 байт
0x0b резерв 8 байт
Перечислим одноранговые команды контроля - см. таблица 6.
Таблица 6. Перечень значений поля «тип запроса»
Тип запроса Команда
0x01 Проверить доступность устройства
0x02 Проверить состояние устройства
0x03 Проверить класс устройства
0x04 Проверить тип устройства
0x05 Запросить адрес устройства
0x06 Запросить загрузку устройства
Рассмотрим структуру пакетов для команд проверки доступности/состояния устройства. Допускаются классы команд 0x01,0x02,0x04 (Таблицы 7-9).
Таблица 7. Структура блока данных для команды «Запросить доступность устройства или период опроса»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x00 1 байт
2 Класс запроса/ответа 0x01 или 0x04 1 байт
4 Тип запроса/ответа 0x01 или 0x02 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов М 2 байта
7-Ы Идентификатор объекта
\
Таблица 8. Структура блока данных для команды «Установить проверку доступности устройства по таймеру»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x00 1 байт
2 Класс запроса/ответа 0x02 1 байт
4 Т ип запроса/ответа 0x01 или 0x02 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов М 2 байта
7-Ы Идентификатор объекта
Период опроса 4 байта
Таблица 9. Структура блока данных «Ответ о доступности устройства»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x01 1 байт
2 Класс запроса/ответа 0x01 или 0x02 1 байт
4 Тип запроса/ответа 0x01 или 0x02 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов М 2 байта
7-Ы Идентификатор объекта
Состояние 0 или 1 1 байт
Таблица 10. Структура блока данных «Ответ о периоде»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x01 1 байт
2 Класс запроса/ответа 0x04 1 байт
4 Тип запроса/ответа 0x01 или 0x02 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов М 2 байта
7-Ы Идентификатор объекта
Период опроса 4 байта
Комментарий. По умолчанию опрос будет вестись по идентификатору технического средства. При этом, сервер САУКТ может широковещательно опрашивать несколько устройств, потому он будет вычислять по номеру ТКУ его 1Р. Для серверов САУКТ некоторых устройств, таких как ТКМС номер ТКУ игнорируется, т.к. опрашиваемое устройство только одно.
Проверить класс/тип устройства. Допускаются классы команд 0x01.
Таблица 11. Структура блока данных «Запросить доступность устройства или период опроса»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x00 1 байт
2 Класс запроса/ответа 0x01 1 байт
4 Тип запроса/ответа 0x03 или 0x04 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов М 2 байта
7-Ы Идентификатор объекта
Таблицу 12. Структура блока данных «Ответ на запрос о доступности устройства или периоде опроса»
№ п/п в поле «Блок данных» Наименование Значение Длина
1 Т ип пакета 0x00 или 0x04 1 байт
2 Класс запроса/ответа 0x01 1 байт
4 Т ип запроса/ответа 0x03 или 0x04 1 байт
5 Т ип адреса 0x01 или 0x05 1 байт
6 Количество объектов M 2 байта
7-N Идентификатор объекта
Длина строки
Строка
Выводы
Как мы отмечали, отсутствие проработанной методологии разработки программного и аппаратного обеспечения в сфере экспериментальных и узкоспециальных сетей, в особенности в отечественной разработке, приводит к возникновению разнородных подходов к реализации подобных сетей, основывающихся на интуиции и опыте разработчиков, что приводит к использованию большого числа разнообразных методов, решений, моделей. Все это приводит как к увеличению стоимости разработки и поддержки таких сетей, к разработке единичных, малосовместимых образцов, так и к сложностям интеграций подобных разнородных частных решений, и, как следствие, к значительному росту затрат.
Мы предприняли попытки разработки как методологии синтеза протокола, так и, собственно, разработки самого протокола.
Предложенные нами методология синтеза протокола на основе математической модели и сам протокол предлагаются к широкому обсуждению.
Библиографический указатель:
1. Virgin Galactic [Электронный ресурс] Режим доступа: URL: http://www.virgingalactic.com/.
2. Big Dog Overview //Boston Dynamics [Электронный ресурс] URL: http://www.bostondynamics.com/img/BigDog_Overview.pdf .
3. Erico Guizzo How Google's Self-Driving Car Works - IEEE
Spectrum". Spectrum.ieee.org. Retrieved February 26, 2013. [Электронный ресурс] Режим доступа: URL: http://spectrum.ieee.org
/automaton/robotics/artificial-intelligence/how-google-self-driving-car-works.
4. B1 US patent 8630897 B1, Luis Ricardo Prada Gomez; Andrew Timothy Szybalski Sebastian Thrun & Philip Nemec et al., "Transportation-aware physical advertising conversions", published 2014-01-14, assigned to Google Inc. [Электронный ресурс] Режим доступа: URL: http://worldwide.espacenet.com/publicationDetails/biblio?CC=US&NR =8630897&KC=&FT=E&locale=en_EP.
5. Сайт проекта Mars One. [Электронный ресурс] Режим доступа: URL: http://www.mars-one.com/.
6. Wischhof L. Self-Organizing Communication in Vehicular Ad Hoc Networks. Doktor-Ingeneiur (Dr.-Ing.) Dissertation [Текст] Braunschweig 2007 ISBN 978-3-8322-6246-4. [Электронный ресурс] http://doku.b.tuharburg.de/volltexte/2007/341/pdf/diss_wischhof.pdf.
7. Azimi R., Bhatia G., Rajkumar R., Mudalige P. Vehicular Networks for Collision Avoidance at Intersections // Society for Automotive Engineers (SAE) World Congress,April,2011, Detroit, MI, USA. [Электронный ресурс] http://users.ece.cmu.edu/~sazimi/SAE2011.pdf.
8. Eichler S., Ostermaier B., Schroth C.,Kosch T. Simulation of
Car-to-Car Messaging: Analyzing the Impact on Road Traffic. // Proceedings of the 13th Annual Meeting of the IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) : IEEE Computer Society, 2005.-13th Annual Meeting of the IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS).- Atlanta, USA, p. 4.- [Электронный ресурс] Режим доступа: https://www.alexandria.unisg.ch/Publikationen/30961
https://www.alexandria.unisg.ch/export/DL/40603.pdf.
9. Gozalvez J., Sepulcre M., Bauza R. IEEE 802.11p Vehicle to Infrastructure Communications in Urban Environments // IEEE Communications Magazine, vol. 50, no. 5, pp. 176-183, May 2012.- [Электронный ресурс] URL: http://www.uwicore.umh.es/V2I-measurement-campaign/.
10. IEEE 802.15 Working Group for WPAN Monday, 17 February 2014 [Электронный ресурс] URL: http://www.ieee802.org/15/.
11. Silva D.; Ghanem M.; Guo Y. (2012). WikiSensing: An Online Collaborative Approach for Sensor Data Management // Sensors 12 (12): 13295. doi:10.3390/s121013295 [Электронный ресурс] Режим доступа: URL: http://www.mdpi.com/1424-8220/12/10/13295 http://www.mdpi.com/1424-8220/12/10/13295/pdf.
12. Кручинин С.В. К вопросу о терминологии в области мобильных сетей транспортных средств С.В. Кручинин // Теория и техника радиосвязи. Воронеж, 2011. - № 1. - С. 117-120.
13. Финогеев А. Г., Богатырев В. Е., Маслов В. А., Финогеев А.А. Мониторинг и поддержка принятия решений в системе городского теплоснабжения на базе гетерогенной беспроводной сети / А.Г. Финогеев, В.Е. Богатырев, В. А. Маслов, А.А. Финогеев // Известия Волгоградского государственного технического университета: межвуз. сб. науч. ст. № 3(76) / ВолгГТУ. - Волгоград, 2011. (Сер. Актуальные проблемы управления, вычислительной техники и информатики в технических системах. Вып.10). - С. 73-81.
14. Кручинин С. В. Математическая модель контролируемых устройств / С.В. Кручинин // Известия Волгоградского государственного технического университета, 2013. - Т. 17. - № 14 (117). -С. 19-20.
15. Вишняков А.В., Кручинин С.В., Кручинина М.Ю. Язык описания топологии вычислительных сетей NTDL / А.В. Вишняков, С.В. Кручинин, М.Ю. Кручинина // Известия Волгоградского государственного технического университета, 2012. - № 15. - С. 126129.
16. Вишняков А.В., Зотов С.В., Кручинин С.В., Кручинина М.Ю. Опыт разработки архитектуры программного обеспечения САПР вычислительных сетей / А.В. Вишняков, С.В. Зотов, С.В. Кручинин, М. Ю. Кручинина // Теория и техника радиосвязи. Воронеж, 2013. - № 1. - С. 98-104.
17. Кручинин С.В. Роуминг как необходимое свойство ad hoc сетей транспортных средств / С.В. Кручинин // Научноисследовательские публикации, 2013. - № 1. - С. 66-86.
18. Кручинин С.В. Способ тестирования сетей путем моделирования работы пользователей / С.В. Кручинин // Новый университет. Серия: Технические науки, 2012. - № 3. - С. 45-48.
19. Кручинин С.В., Зотов С.В. Программа тестирования связи ЕСУ ТЗ путем моделирования работы пользователя / С.В. Кручинин, С.В. Зотов // Свидетельство о государственной регистрации программы для ЭВМ № 2011612245 от 17.04.2011. - Москва. - Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
20. Кручинин С.В. и др. Сервер контроля узлов сети обмена данными / С.В. Кручинин, Д.В. Вихорев, С.В. Зотов, В.В. Поплав-ский // Свидетельство о государственной регистрации программа для ЭВМ № 2011614929 от 23.06.2011. - Москва. - Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
21. Кручинин С.В. Телекоммуникационный модуль сопряжения абонентской и транспортной сетей / С.В. Кручинин // Патент на полезную модель Яи 128 052 Ш Опубликовано 10.05.2013 бюл. №13 ; заявка № 2012151805/08; заявл. 03.12.2012. - Москва. - Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
22. Кручинин С.В., Кручинина М.Ю. Маршрутизатор абонентский в децентрализованных одноранговых сетях транспортных средств / С.В. Кручинин, М.Ю. Кручинина // Перспективы развития информационных технологий: сб. мат. XI межд. науч-практ. конф. -Новосибирск, 2013. - С. 136-139.
23. Кручинин С.В. Математическая модель контролируемых устройств // Известия Волгоградского государственного технического университета, 2013. - Т. 17. - № 14 (117). - С. 19-20.
24. Кручинин С.В. и др. Графическое ядро визуализации и анализа инженерных схем / С.В. Кручинин, А.М. Кузнецов, С.В. Зотов, М.В. Обельченко // Свидетельство о государственной регистрации программа для ЭВМ №2011618938 от 27.09.2011. -Москва. - Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
25. Кручинин С.В. и др. Библиотека графических примитивов / В.В. Бессонов, С.В. Кручинин, А.В. Кузнецов, А.М. Кузнецов, А.А. Свиридов // Свидетельство о государственной регистрации программа для ЭВМ № 2011613834 от 18.05.2011. - Москва. - Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.
Статья поступила в редакцию 21.02.2014