пїњ

—»Ќ“≈« ѕ–ќ“ќ ќЋј ј¬“ќћј“»«»–ќ¬јЌЌќ√ќ ”ѕ–ј¬Ћ≈Ќ»я »  ќЌ“–ќЋя √≈“≈–ќ√≈ЌЌџ’ “≈Ћ≈ ќћћ”Ќ» ј÷»ќЌЌџ’ ”—“–ќ…—“¬

”ƒ  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

пїњ