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

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

Сталкивался. Да вы и сами с ними сталкивались. Подобная аппаратура передачи данных десятилетиями работает в ВВС и ПВО, на кораблях ВМФ.
Сейчас настало время объединить их на основе современных технологий, сделать более универсальными.

Терминал системы обмена данными, входящий в комплекс средств связи С-108 самолета Су-35 сопряжен с радиостанциями, работающими на частотах до 400 МГц. Американская аналогичная система JTIDS (линии связи Link 16) работает в более высокочастотном диапазоне 970-1200 МГц. Чем выше частота, тем потенциально выше скорость передачи данных. У нашей системы она не превышает 25 кбит/с, у американской 115 кбит/с.
У радиостанций системы "Акведук" ниже - 16 кбит/с.

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

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

Так Link 16 уже работает по таким протоколам с пакетами TCP/IP.
Беспилотники вообще используют гражданские каналы. Помните недавний скандал с подслушиванием американских беспилотников в Ираке?

У нас всё это есть. Частотный манёвр даже скорее не для помехозащищённости используется, а для сбивания настроек пеленга. КШС - вообще любимый сигнал "космонавтов". Ну а код с коррекцией ошибок (он же избыточный, так как передаётся и корректирующая информация) - без него делать систему передачи информации нынче моветон.

Используется ли эти приёмы конкретно в АСУВ созвездия - не знаю, но в других системах передачи данных используются.

JazzTime

Да у нас такое есть. И программная перестройка рабочей частоты (ППРЧ, впрочем это еще на Су-27 появилось в своё время, а сухопутчики вот отставали до сих пор). И коррекция ошибок (код Рида-Соломона). И шифрование. Многие другие интересные характеристики не разглашаются, но можно ожидать, что там всё в порядке.
Главное успевать внедрять всё это великолепие в жизнь

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

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

Чем может быть обусловлено применение в наших системах более низкой частоты?

Многими причинами. И первая из них - целесообразность. Чем ниже частота, тем сильнее дифракция на горизонте(огибание земной повехности), меньше затухание в том числе во всякой погоде и лесах.

А какая скорость передачи (ориентировочно) требуется чтобы передать информацию об одной цели с РЛС на ПУ ЗРК?

Для конкретизации - какя скорость передачи потребуется вот для этого комплекса: viewtopic.php?f=14&t=175 - если реализовывать возможноть стельбы по внешнему целеуказанию?

И какие параметры цели длжны быть переданы?

Попробуем посчитать объём информации:
3 координаты - 12байт, 3 составляющие вектора скорости - 6 байт, точная привязка времени измерения - 5 байт, измеренная ЭПР - 2 байта, признак типа цели на основе наблюдаемой траектории и результатов запроса СВОЙ-ЧУЖОЙ - 1 байт. Нужен ещё признак типа пакета, ну и может ещё что упустил. Будем считать 30 байт. Если мы хотим получать такую информацию раз в N секунд по K целям, то нужна скорость 30*K/N байт в секунду или 240*K/N бод(бит/с). Не так уж и много
Скажем 24кбит/c хватит чтоб раз в секунду получать ЦУ по 100 целям.

Тем, что у нас для обмена данными на первых порах выбрали те же радиостанции которые используют для голосовой радиосвязи. На американских самолетах тоже стоят такие же UHF/VHF радиостанции при помощи которых лётчики общаются между собой, с АВКСами и землей. Но у них помимо этого стоит и специальный приемо-передатчик для организации Link 16.

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

Разумно будет применить транспортный/сетевой протокол UDP/IP без подтверждения доставки
http://ru.wikipedia.org/wiki/UDP
Помимо данных пользователя, он предусматривает наличие минимальных IP и UDP заголовков,общим размером 28 байт.
Каждая платформа будет иметь уникальный IP-адресс. Станет возможна маршрутизация и ретрансляция, защита от приема "битых" пакетов. Пакеты будут адресованы конкретным портам, что позволит правильно распределять потоки полученной информации между бортовыми системами (комплексу связи свои пакеты, системе управления оружием свои, системе РЭБ - свои).

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

Вы совершенно правы.
А я за скорость канала принимал скорость на верхнем уровне уже с учётом всех протоколов.

Что там на счёт сложности интерфейса? В низших звеньях управления он может быть предельно прост - "принять команду", "послать сообщение", "принять/послать изображение", ... , "УРА-А-А!!!"( ), в общем, стандартный геймерский набор. И ноут навороченный не нужен солдату/сержанту, а что-то очень простое, надёжное и интуитивно понятное с двумя тумблерами и полудюжиной кнопок.

вот у Андрея_харконена кое-что нашел:

В продолжение темы новых средств управления Российской армии Машина разведки и управления - десантная . Модуль оперативного управления , Компьютеризация и системы управления
еще одна машина для единой сети ПВО на базе МТЛБУ. В единое информационное поле будут объеденины все средства, от танка и зенитного комплекса до ПТРК ПТРК с системой ориентирования и солдата. http://andrei-bt.livejournal.com/tag/ЕСУ%20ТЗ

интересные картинки - особенно интерьер и пр.оборудование

Каждой ЗУР, УР и УАБ тоже по айпишнику, дабы цели правильно распределять.

Надеюсь сразу догадаются использовать IPv6.

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

ИМХО правильнее разработать специализированный протокол, а не брать стандартный IP с его родовыми недостатками.

Угу, и разработать всю сетевую инфраструктуру с софтом ? Очень дорого.
ИМХО, проще "построить" над TCP свою спец. надстройку.

Как минимум проиграем в пропускной способности -> более дорогое коммуникационное оборудование

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

1. Железо по возможности должно быть свое. И работа в этом направлении ведется... (см. тему "Процессоры, САУ....")
2. Стандартное, по каким стандартам? Всяко не по тем по которым оборудование для инет-провайдеров делается....
3. Исходя из п.1 и 2 в предложенном варианте придется на софте реализовывать сначала абсолютно не нужный в данном случае стек TCP\IP а потом уже надстройку.... что то мне это не видится рациональным...

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

1) Чипы для коммуникационного оборудования самим разрабатывать незачем. Проще лицензировать и выпускать на наших мощностях.
2) А чем там стандартные плохи. Есть разные исполнения для разных нужд. Циску, например, используют многие оборонные ведомства.
3) Стоп ! Кто говорил о софтовой реализации TCP/IP ? Софтово только надстройка над ним. Низкоуровненые вещи, на железе. Еще раз подчеркну, стандартном железе. Т.е. вся инфраструктура делается стандартной. Делается совместное предприятие с зарубежной компанией из топовых. Контрольный пакет у Российского представителя. Естественно открывается вся железная и софтовая составляющие. Кстати, разговоры такие сейчас идут.

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

(не специалист, но высказался ибо форум))))

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

для критиков - не настаиваю...

В МО разные ведомства... Если управление по денежно-вещевому довольствию то почему бы и нет...


А что есть чипы в которых TCP/IP аппаратно реализован ?

Да не только в "бухгалтерии" используют. Люди там умеют считать деньги


Хм, Вы серьезно думаете, что в роутерах весь функционал TCP/IP реализуется программно ?

Абсолютно серьезно.
Посмотрите спецификации на чипы, которые входят в роутеры.
Вообще говоря аппаратная реализация TCP/IP абсолютно безсмысленна и даже вообщем-то противоречит идеи разделения сетевых протоколов по уровням...

(Вообще, у меня сильное подозрение что протоколы канального уровня также частично реализованы софтом - например в части формирования пакетов...)

1. Никто не обидется, если я из трёпа про tcp/ip сделаю один пост с основными мыслями?

2. TCP/IP таки реализуется аппаратно и лицензировать там ничего не надо. Сам делал простейшие прошивки для ПЛИС, которые обменивались данными по ethernet.