Автоматические системы управления боевыми действиями

Форум о новинках и разрабатываемых образцах военной техники

Re: Автоматические системы управления боевыми действиями

Сообщение EvMitkov » 21 авг 2013, 22:23

Андрей, дорогой Вы мой! - говорю же по чести и откровенно - я уже слишком устарел для того, чтобы судить о таких вещах.
Для меня - работающее радио с устойчивой связью - уже подарок был.
Древний, примитивный и тяжелючий "Радий-М", если был у каждого бойца группы - верхом счастья считалось. А уж многоканальные забугорные уоки-токи...

В этой теме многое может сказать Борис Викторыч. А я - буду с искренним любопытством следить за материалами. И - немножко мечтать. :mrgreen:

С уважением, Е.М.
С Дона - выдачи нет!
Аватара пользователя
EvMitkov
 
Сообщения: 13884
Зарегистрирован: 02 окт 2010, 02:53
Откуда: Россия, заМКАДье; Ростовская область.

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:16

Дмитрий Кандауров (dragon_first_ru)
http://dragon-first-ru.livejournal.com/34318.html

АСУВ ЕСУ ТЗ
Jun. 20th, 2012 at 2:30 AM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»,
или марш по граблям

Уважаемые читатели!

27 апреля 2012 года тогда еще Президент России Дмитрий Медведев своим Указом № 115[1] назначил генерал-полковника Владимира Валентиновича Чиркина (бывшего до того командующим войсками Центрального военного округа), главнокомандующим Сухопутными войсками.

Этим же Указом на должность командующего войсками Центрального военного округа назначен генерал-полковник Валерий Васильевич Герасимов, который, тем не менее, вплоть до 9 мая сего года продолжал исполнять обязанности заместителя начальника Генерального Штаба Вооруженных Сил Российской Федерации.

Задержка с фактическим переводом Герасимова в славный город Екатеринбург была, очевидно, связана с тем, что Валерий Васильевич должен был командовать парадом в г. Москве в честь годовщины Победы.

Кстати, Центральный военный округ - уже третий по счету в карьере генерал-полковника Герасимова, которым он командует. (Ленинградский военный округ (11 декабря 2007 — 5 февраля 2009), Московский военный округ (5 февраля 2009 — 23 декабря 2010), и вот теперь – Центральный ВО со штабом в Екатеринбурге.

Упаси нас Бог от каких-либо аналогий, но почти сразу же после войны в 1948 году, Уральским военным округом со штабом все в том же Екатеринбурге (тогда он назывался Свердловск) был отправлен командовать некто маршал Жуков Георгий Константинович. Правда, сначала он покомандовал Сухопутными войсками и Одесским военным округом.

И все тем же Указом от 27 марта 2012 года генерал-полковник Александр Николаевич Постников-Стрельцов был переведен на должность, которую ранее (до своего назначения командующим войсками Центрального военного округа) занимал генерал-полковник Герасимов.

Различных версий, озвученных в прессе и «тырнетах» в связи с рокировкой трех генерал-полковников «под занавес» президентского срока Д.А. Медведева было предостаточно. Мы не будем заниматься конспирологией и примем «на веру» официальную: пресловутая ротация. Которая предусматривает периодический перевод военнослужащих в различные округа на равнозначные должности. Однако, формально должность главнокомандующего Сухопутными войсками является более высокой (к тому же более «приарбатской»), по сравнению с должностью командующего войсками военного округа, и, соответственно генерал-полковник Чиркин однозначно пошел на повышение.

А вот генерал-полковник Герасимов при переводе формально «потерял» в должностном окладе. Должность заместителя начальника Генерального Штаба ВС РФ была на один тарифный разряд выше. Но есть и приятный момент. Доступ к различным ресурсам (войскам, материальным средствам, деньгам и т.д.) у командующего войсками нынешнего округа несравненно больше, чем у заместителя НГШ.

Является ли повышением назначение генерал-полковника Постникова-Стрельцова?

Хороший вопрос. По формальному признаку (тарифный разряд) – нет. А вот по степени влияния на ключевую фигуру современных реформ – начальника ГШ – однозначно да.

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

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

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

Что касается генерал-полковника Чиркина, то нынешний главком для ЕСУ ТЗ – отнюдь не чужой. Еще в должности заместителя командующего Московским военным округом он вплотную занимался вопросами ЕСУ ТЗ (при проведении испытаний и опытной эксплуатации системы еще во 2 гвардейской Таманской мотострелковой дивизии). В этой же должности он принимал участие в российско-американском учении «Торгау-2007», проходившем в многонациональном центре подготовки войск «Граффенвер» (Германия), где воочию мог ознакомиться с американским подходом к использованию средств автоматизации при управлении войсками.

Тем более ценен его опыт (в том числе и как бывшего разведчика!).

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

Цитата:

«Разработка ЕСУ ТЗ стала первой работой такого уровня после достаточно длительного перерыва. В создании системы принимает участие более 50 предприятий промышленности. Отмечу, что ведущие зарубежные страны - США, Германия, Италия, Франция также уделяют пристальное внимание вопросам автоматизации в тактическом звене.

В настоящее время доработка отечественной ЕСУ ТЗ находится в завершающей стадии. В июне этого года спланировано проведение комплексной проверки устранения замечаний, выявленных в ходе государственных испытаний. По её результатам можно будет сделать выводы о соответствии системы требованиям современного боя и принять решение об объёмах поставок в войска. (Курсив мой –Д.П.).

Конец цитаты.

Полностью интервью можно прочитать здесь:

http://www.redstar.ru/index.php/compone ... brazovaniy

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

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

На дворе – середина 2012 года.

Кроме постоянно меняющего свою конфигурацию (и пока единственного!) бригадного комплекта системы, который находится в опытной эксплуатации в 5 омсбр 20 армии Западного военного округа, поставки в другие мотострелковые бригады даже не начинались.

Э?

Напомню, что аналогичная (тактического звена) американская система АСУВ «Force XXI Battle Command Brigade and Below» (FBCB2) класса С2, о которой рассказывалось в предыдущих постах этого блога, прошла путь от выдачи технического задания до начала серийных поставок в войска всего за 6 (шесть) лет (1995-2001 г.).

В 2002-2004 годах данная система уже активно использовалась американскими военными при подготовке и в ходе боевых действий в Ираке.


В качестве справки:

За 12 лет разработки и попыток внедрения ЕСУ ТЗ сменилось:

как минимум два главных конструктора ЕСУ ТЗ;

два генеральных директора концерна «Созвездие»;

два командира 2 гв мсд и три командира 5 омсбр;

два командующих 20 армией;

четыре командующих Московским (Западным) военным округом;

три главнокомандующих Сухопутными войсками;

…а также три редакции Боевых уставов Сухопутных войск.


Официальная историю вопроса создания автоматизированной системы управления тактическими воинскими формирования (Единой систему управления тактическим звеном) в новейшей истории ВС РФ выглядит следующим образом :


1. Организация:

2000 г. Указом Президента Российской Федерации В.В. Путина принято решение о разработке ЕСУ ТЗ (единой системы управления тактическим звеном (дивизия – отделение)).

Июнь 2000 г. Приказом генерального директора ФГУП «ВНИИС» для координации разработки ЕСУ ТЗ образован Московский филиал ФГУП «ВНИИС» - «Научно-производственный центр автоматизации управления и связи». Директором НПЦ АУС назначен А.П. Царёв. Он же был назначен генеральным конструктором ЕСУ ТЗ (приказом начальника РАСУ, РФ, №194 от 19.06.2000 по согласованию с ГШ ВС).

Ноябрь 2001 г. Начальник ГШ ВС РФ утвердил ТТЗ на ОКР «Создание базового комплекта ЕСУ ТЗ» (ОКР «Созвездие-М»). Головным исполнителем ОКР «Созвездие-М» назначен ФГУП «ВНИИС», г. Воронеж.

2004 г. Во исполнение Указа Президента РФ № 993 от 29.07.2004 г. создано ОАО «Концерн «Созвездие» - правопреемник ФГУП «ВНИИС». Генеральный директор ОАО - Юрий Викторович Сидоров. НПЦ автоматизации управления и связи переименован в НПЦ автоматизированных управляющих систем.

Всего в создании системы принимало участи от 20 до 50 предприятий, как входящих в концерн, так и «сторонних».

18 января 2010 г. Тогда еще председатель правительства В.В. Путин побывал в Концерне «Созвездие» и провел совещание по вопросам выполнения указа о создании ЕСУ ТЗ.

Январь 2011 – март 2012 г. Концерн «Созвездие» получает контрольные пакеты акций ОАО «Электросигнал» (Воронеж), ФГУП «Научно-исследовательский институт электронной техники» (Воронеж), ФГУП «Опытный завод «Тамбоваппарат» (Тамбов) и московского ФГУП «Научно-исследовательский институт систем связи и управления». При этом предприятия, бывшие ранее ФГУП становятся ОАО. С включением указанных предприятий в интегрированную структуру «Созвездия» общее их количество достигает двадцати.



Август 2011 г. генеральным директором концерна "Созвездие" назначен Азрет Юсупович Бекиев. Полномочия предыдущего гендиректора Юрия Сидорова были досрочно прекращены.

Февраль 2012 г. В концерне побывал вице-премьер Правительства РФ Д.О.Рогозин, курирующий вопросы ОПК.

Январь - 16 апреля 2012 г. Реорганизация головных предприятий концерна в Воронеже. За этот период сокращено (по различным данным) до 1,5 тысяч должностей. При этом около 900 человек уволено.


2. Планы по созданию системы:

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

2002-2005 гг. Второй этап: разработка полного комплекта нормативно-технических документов, технических и программных средств, информационно-технической основы; создание опытных образцов подсистем, объединенных единым системотехническим замыслом.

2005-2010 гг. Третий этап. Обеспечивается создание системы в полном объеме, интегрирующей функции управления, разведки, связи, радиоэлектронной борьбы, навигации и опознавания и позволяющей с максимальной эффективностью осуществлять управление тактическими воинскими формированиями.

1 февраля – 1 декабря 2010 г. Проведение опытной войсковой эксплуатации поставочного комплекта для мотострелковой бригады.

С 2010 – 2015 гг. Серийные поставки изделий в войска для укомплектования мотострелковых бригад.

2015 г. Завершение оснащения общевойсковых бригад Сухопутных войск ВС РФ комплектами ЕСУ ТЗ.

3. Реализация:

В реальности было примерно так:

2006 г. Проведен первый этап государственных испытаний базового комплекта. Результат: система не обеспечивает автоматизацию функций управления в тактическом звене в соответствии с техническим заданием (кроме подсистемы РВиА). Учитывая необходимость доработки системы, принимается решение о поставке во 2 мсд Московского военного округа элементов ЕСУ ТЗ для проведения опытной войсковой эксплуатации в 2007-2009 гг. Генеральным конструктором АСУ тактического звена назначен В.А.Потапов.

1 февраля – 1 декабря 2009 г. Расформирование 2 мсд МВОи формирование на ее базе 5 омсбр 20 А ЗВО. Проведение опытной войсковой эксплуатации поставочного комплекта для мотострелкового батальона бригады (на БТР) со средствами усиления.

Декабрь 2009 г. - Экспериментальное (исследовательское) батальонное тактическое учение с применением средств ЕСУ ТЗ. Проведение второго этапа государственных испытаний.

Результат – система крайне "сырая". Доработка системы планируется и осуществляется в период с января по октябрь 2010 года в рамках модификации системы, получившей название «Созвездие М».

Октябрь 2010 г. Проведение командно-штабного учения с управлением и несколькими подразделениями 5 омсбр с применением комплекса ЕСУ ТЗ.

Результат: выявлено огромное количество недоработок как в области ПО, так и средств передачи данных. Принято решение о доработке системы до уровня «Созвездие М2».

Май 2011 г. Проведение очередного (третьего) этапа Государственных испытаний «Созвездия М» с элементами «Созвездия М2».

Результат: устранение недостатков планируется до октября 2011 г.

Октябрь 2011 г. Проведение исследовательского бригадного учения с применением ЕСУ ТЗ в версии «Созвездие М2».

На учениях присутствуют 140 представителей Минобороны, органов военного управления, представители Совета Федерации и Генштаба Вооруженных сил России. Было задействовано более 1,5 тысячи единиц различной боевой техники и свыше 1200 военнослужащих 5-й отдельной мотострелковой бригады. Одновременно проводилась работа межведомственной комиссии (МВК).

Результат: Принятие на вооружение системы отложено до устранения выявленных недоработок.

Июнь 2012 г. Проведение проверки устранения недостатков системы в версии «Созвездие М2», о котором в своем интервью говорил генерал-полковник Чиркин.


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

Поговорим о «коренных» проблемах, с которыми столкнулись военные и создатели системы, в результате непродуманности всех вопросов идеологии создания системы еще на стадии эскизного проектирования!

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

Итак:

1. Изначально некорректно и очень расплывчато сформулированное техническое задание. В этом разработчики системы регулярно (и справедливо!) упрекают военных. Постоянные «уточнения», вносимые в ТЗ по результатам очередного исследовательского учения, значительно затрудняют проведение работ. В ходе испытаний, проводимых военными, постоянно возникают т.н. «отдельные недостатки», требующие внесения изменений в систему. При этом, некоторые из них принципиально меняют не только отдельные «узлы и агрегаты», но и принципиальные подходы и направление развития системы, вынуждая разработчиков изменять принципы и алгоритмы работы аппаратной и особенно - программной составляющей системы. В результате - до сих пор не ясно, например, что же мы хотим получить «на выходе» и к какому, собственно, классу относится создаваемая система.

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

Такая точка зрения выражается, например, в желании некоторых генералов иметь в тактическом звене управления систему, которая бы сама собирала все необходимые данные, производила их оценку и предлагала командиру несколько(!) вариантов решения на бой с указанием различных вероятностных параметров. Таких, например, как достигаемый в ходе боя уровень потерь противника и своих войск, скорость и глубина продвижения наступающей стороны, вероятностные характеристики достижения успеха в бою и т.д. То есть, выдвигается абсолютно необоснованное требование по созданию системы класса С3-С4ISR. (Подробнее о классификации и признаках систем такого класса смотрите здесь: http://dragon-first-ru.livejournal.com/ ... tml#cutid1) . Пока же ЕСУ ТЗ "не дотягивает" даже до уровня С2 (Командование и контроль). Но к этой точке зрения мы еще вернемся.

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

4. Четвертый пункт является, так сказать, производным от первых трех. Это методика проведения испытаний. Ни разработчики, ни военные так и не пришли к единому мнению относительно основных критериев эффективности и работоспособности системы и, следовательно - нужности ее в войсках.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:18

Комментарии:

lazy_sphinx
Jun. 20th, 2012 09:18 pm (UTC)
По пунктам
1. ТЗ, которое пишет заказчик это вообще какой-то не встречающийся в природе вымысел. Единственное возможное назначение - это последующая торговля с заказчиком по поводу сроков и объема исправлений. Впрочем, судя по тому что Вы пишете - так и происходит ) ГОСТы по поводу разработки ПО писались для условий когда разрабатываемые системы решали на порядок более простые задачи.
2. Плод того самого идеального ТЗ на все сразу в котором потонет все что угодно. С генералами (и генеральными директорами, кстати, тоже) имеет смысл обсуждать документ, который в состоянии понять обе стороны. Кстати, несколько вариантов тактического решения - не такая уж и утопия - не дешево, конечно, и довольно коряво будет поначалу, но самообучающиеся системы придуманы не вчера и,
3. Им (самообучающимся) не нужны четкие алгоритмы. Более того - четкие алгоритмы управления в системах с участием людей - это вообще ненаучная фантастика.
4. А четкая методика проведения боевых действий - бывает? )))

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


vinfdsc
Jun. 20th, 2012 10:06 pm (UTC)
Re: По пунктам
1. "Нечётких" алгоритмов не бывает. Любой алгоритм, например, алгоритм нечёткой кластеризации по C-средним, всё равно очень даже "чёткий", как и пацаны, которые хотят его использовать...
2. Чёткие алгоритмы в системах управления с участием людей вполне даже бывают, например, алгоритм автомата тяги самолёта, алгоритм горизонтальной стабилизации самолёта, алгоритм навигационно-вычислительного устройства, алгоритмы логистики, планирования, хозяйственного учёта и т.п.
Вообще, назовите хоть один "нечёткий" алгоритм. Алгоритм - это последовательность команд, которая приводит к решению задачи, а последовательность команд нечёткой быть не может. Она или есть, или её нет.
Она лишь может хорошо или плохо вписываться в автоматизируемые процессы, автоматизировать их на различном уровне, быть настраиваемой или ненастраиваемой и т.п.
3. Где вы видели самообучающиеся алгоритмы - это вообще вопрос. В общем виде таких в природе не существует, задача написания искусственного интеллекта не решена. А в частностях всё, что обучается, пишется очень сложно и обучается лишь в очень узких рамках.
А теперь контрольный вопрос в голову: вы можете поставить такие рамки, чтобы программисты могли создать в них самообучающийся алгоритм?
Если да, было бы интересно услышать, что же это за рамки такие.

Гораздо легче просто автоматизировать те участки процесса, которые не видоизменяются и ничего экстра ординарного не требуют. О чём автор блога, видимо, и пишет.


lazy_sphinx
Jun. 21st, 2012 06:20 am (UTC)
Re: По пунктам
Ну, я чуть снижу градус ерничества, ладно?
1. Вы в словосочетании четкий алгоритм - зря к прилагательному привязались - там с существительным надо оперировать.
Оптимизационные алгоритмы - они вполне себе четкие, что не мешает даже простейшим системам, которые управляются иерархической системой правил вести себя вполне даже не алгоритмически.
Можно это и настраиваемой системой называть. Собственно, если под "системой" иметь в виду только программный код - так оно и будет.
2. Алгоритмы автоматов тяги бывают в автоматах тяги )) Они не претендуют на изменение указаний пилота в процессе перехода из одного состояния в другое. И число состояний у автомата, кстати не велико.
3. Не про самообучающиеся алгоритмы речь. Вполне себе работают, например, не особенно недорогие системы, которые набором ситуационных правил управляются. Самообучение в них, например, может выглядеть как пополнение базы правил или весовых коэффициентов решений в зависимости от оценки результата выполнения задачи экспертом.

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

>Гораздо легче просто автоматизировать те участки процесса,
>которые не видоизменяются и ничего экстра ординарного не
>требуют. О чём автор блога, видимо, и пишет
Для начала - да. Кстати, по тому что автор писал раньше - от первых двух "C" реализованных в приличном виде заказчик уже должен быть счастлив.


vinfdsc
Jun. 21st, 2012 10:18 am (UTC)
Re: По пунктам
> набором ситуационных правил управляются.
Вот, видите. Оказалось, всего-навсего, что вы хотите, чтобы система донастраивалась военными.

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

Кроме этого, чтобы написать какие-то правила, нужен некий язык. Для этого языка нужно:
1. Написать ТЗ, чтобы разобраться, что за язык нужен (скажем, можно ограничиться просто комбинацией уже существующих правил, или нужно что-либо типа SQL, или язык должен быть графический и т.п.)
2. Написать интерпретатор, причём если язык будет решать сложные задачи достаточно просто, то и интерпретатор будет сложно разработать
3. Обучить настройке правил военных. Как использованию настраиваемой системы с языком правил, так и, собственно, проектированию этих правил

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


lazy_sphinx
Jun. 21st, 2012 10:33 am (UTC)
Re: По пунктам
Ну, так никто и не говорит, что это просто. При всех сложностях такого подходя - такое решение куда более реалистично, чем попытка единовременно написать ТЗ до уровня, о котором идет речь в п 3.


vinfdsc
Jun. 21st, 2012 10:47 am (UTC)
Re: По пунктам
Ну с этим согласен. Но гораздо легче ничего не писать и чтобы всё сделали программисты.


lazy_sphinx
Jun. 21st, 2012 10:54 am (UTC)
Re: По пунктам
За ваши деньги - любой каприз! ))))


vinfdsc
Jun. 21st, 2012 12:07 pm (UTC)
Re: По пунктам
Да, к сожалению, настраиваемые правила как раз такой каприз. Как я уже писал:
1. Военные сами должны будут писать такие правила
2. Язык правил будет сложно не только изучить и написать, но и, собственно, создать. В том числе, создать достаточно гибким, чтобы не переделывать его постоянно


lazy_sphinx
Jun. 21st, 2012 12:20 pm (UTC)
Re: По пунктам
Военные и так переделывают правила. Например, исправляя боевой устав (см. выше по тексту). На счет сложностей и выразительных возможностей языка - опять же есть устав, который можно "перевести" буквально - на первые несколько лет внедрения/обкатки более чем достаточно.
Собственно, как и в первом приближении учетно/аналитических систем - когда фактически повторяются "бумажные" процедуры и способы работы - не стоит придумывать что-то радикально новое - лучше дать возможность использовать привычные профессиональные способы работы.
А что до постоянной доработки - ну, это опять же будни любых систем управления - тут можно разве что целью поставить минимальную стоимость таких работ.


vinfdsc
Jun. 21st, 2012 01:13 pm (UTC)
Re: По пунктам
> опять же есть устав, который можно "перевести" буквально
Устав, он для людей. В правила перевести его может быть вообще невозможно.
Плюс к этому, устав могут перевести, если это возможно, именно программисты.
Кроме этого, программа не устав исполняет - устав для бойца. А программа по своим правилам работает. Ей нужны какие-то совсем другие правила, в том числе объясняющие ей то, что не написано в уставе.

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

> А что до постоянной доработки - ну, это опять же будни любых систем управления
Дорабатывать можно разное и по-разному. В этом и суть, что сделать язык правил, описывающий такие вещи, может быть настолько сложно, что потребуется большее количество доработок, нежели если сами программисты всё вручную запрограммируют, без языка правил.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:22

АСУВ ЕСУ ТЗ
Jun. 20th, 2012 at 7:33 PM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

(Часть 2)


Начнем с первого пункта.
С осознания, так сказать, сложности стоящей перед разработчиками задачи.
Ибо, при подготовке технического задания для создания любой более-менее сложной системы управления (которая претендует в своем названии на слово «автоматизированная»), необходимо очень четко представлять то, ЧТО мы собственно, собираемся автоматизировать. А еще – КАК это что-то работает в режиме неавтоматизированном. То есть – ручном.

Далее – необходимо проанализировать те задачи и функции, которые выполняет эта система, а также осознать – КАКОВА ЦЕЛЬ работы по автоматизации существующей системы управления?

То есть, если мы в качестве цели выдвигаем простое оснащение каждого пункта управления большими (и красивыми!) импортными мониторами, а сами на этом фоне планируем «попилить» народную денежку (и немалую!) – то это будет одно техническое задание.

Стационарный центр боевого управления Центрального военного округа.
Фото с учения «Центр 2011»



Если мы хотим «всего лишь» кардинально сократить непроизводительный, нетворческий ручной труд командиров и офицеров штабов всех уровней – то техническое задание будет совершенно другим.

Работа на пункте управления тактического звена.
Фото с учения "Центр 2011"



Если мы хотим помимо собственно сокращения доли ручного труда еще и сократить организационную часть цикл боевого управления (что поверьте – не одно и то же!), одновременно повысив КАЧЕСТВО решаемых управленческих задач – то на выходе мы получаем уже третий вариант технического задания.

Я пока понятно объясняю?

Далее.

Определившись с целью и досконально ЗНАЯ, как работает система в «ручном» режиме, мы должны проанализировать все те функции, которые выполняют элементы системы управления ВО ВСЕХ вариантах своей работы (оборона (все способы), наступление (опять же - все способы), передвижение, расположение на месте, проведение специальной операции и т.д).

А затем определить – какие конкретно функции, какого конкретного элемента системы (должностного лица управления и штаба) мы будем, а главное - сможем автоматизировать, исходя из доступных нам современных и перспективных средств автоматизации.

Ну и «на сладкое»:

Определившись со всем этим делом, мы должны определить достигаемый (расчетный) уровень автоматизации системы. Говоря другими словами – сколько информационных операций, функций, процессов и задач сможем «отобрать» у человека и полностью передать машине?

Для примера скажу, что общее количество офицерского состава в мотострелковой бригаде, непосредственно вырабатывающих решения (участвующих в подготовке боя) и осуществляющих функции управления достигает 180 человек, каждый из которых решает при подготовке и входе управления подразделениями при выполнении боевых задач до 200 различных информационных операций. А при изменении характера (вида) боевых действий эти операции могут кардинально изменяться. Например, ведение наступления может осуществляться, как минимум десятком способов. А теперь умножьте 200 на 180 и еще на несколько десятков.

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

С ходу не получается, да?

Еще одним аспектом, существенно осложняющим подготовку технического задания для создания ТЗ автоматизированной системы управления тактического звена, является фактор мобильности, как органов (и пунктов) управления, так и объектов управления.

С этой точки зрения, система управления атомной электростанцией, например, – проста, как погремушка. Ибо базируется на стационарных пунктах управления и системах связи, и управляет стационарными же объектами, число которых ограничено и строго постоянно. У военных же все движется, течет и изменяется перманентно.

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

Как вы думаете, уважаемые читатели, являются ли перечисленные выше факторы упрощающими жизнь создателей ТЗ, и разработчиков собственно автоматизированной системы?

Это я еще не говорю об оперативной постановке задач и военно-научном сопровождении работ по созданию элементов системы. Этот этап должен является как бы продолжением работы по написанию собственно технического задания. То есть, даже при очень подробно написанном ТЗ, существует постоянная потребность разъяснения разработчикам (как правило, – сугубо гражданским людям) частных требований к созданию конкретных аппаратно-программным средств и особенностей их применения в условиях современной войны. И этим то же кто-то должен заниматься.

Но это так, к слову.

Резюмируем:

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

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

В текущей момент времени данные требования, предъявляемые к создателям технического задания являются достаточно противоречивыми. Потому, что специалистов в области управления общевойсковыми соединения и воинскими частями ранее готовила Академия им. Фрунзе, а специалистов в области компьютерной техники, программирования и средств связи (передачи информации) готовила Академия связи им. С.М. Будённого. Причем в своем подавляющем большинстве такие редкие кадры в Вооруженных Силах, как правило, не задерживались.

Сейчас в нашей доблестной армии, число специалистов, которые бы обладали вышеперечисленными качествами одновременно в силу названной и еще целого ряда причин,– есть величина исчезающее малая. Не говоря уже о возможности, а главное – способности и желания представителей соответствующих армейских структур разъяснять специалистам промышленности «азбучные истины» военного дела на этапе оперативной постановки задач!

Однако, читатель, регулярно посещающий сайты типа «Сделано у нас», «Глобальной авантюры» и прочих «твоверов», возмутится: «Но, ведь у нас есть большие начальники, которые «вникают….!»

Безусловно. О таких начальниках, которым по должности положено «вникать», а также о результатах их работы - читайте мой предыдущий пост.

Кроме того, Ваш покорный слуга оставляет за собой право полагать, что хождение с умным видом по различным отечественным предприятиям ОПК, а также командировки за народные денежки на зарубежные военизированные «выставки достижений капиталистического хозяйства», НЕ ЯВЛЯЕТСЯ признаком способности должностного лица внятно изложить промышленности, что же от нее собственно, требуется. Особенно в области АСУВ.

Да, безусловно, есть у нас и очень грамотные в военном отношении генералы.

Но.

Вы сможете представить себе генерала, или даже полковника, который в современных условиях в перерывах между руководством очередными организационно-штатными мероприятиями, подготовкой к строевому смотру, очередному показному учению и рассмотрением договора с какой-нибудь аутсорсинговой компанией, занимался бы еще анализом и осмыслением задач создания АСУВ?

Лично я – нет.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:31

АСУВ ЕСУ ТЗ
Jun. 21st, 2012 at 9:52 PM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

(Часть 3)

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

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

Однако все это – общие слова.

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

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

И вот с этим-то у создателей технического задания, как правило, происходит «полный затык».

Ибо, как уже было сказано выше – военная боевая система и ее система управления, в отличии от аналогичных гражданских систем, является:

а) пространственно распределенной.

б) мобильной (в смысле геопространственной ориентации как пунктов управления, так и объектов управления).

в) не имеющей жесткой организационно-штатной структуры и работающей в условиях перманентного изменения параметров своих элементов (состав и состояние системы управления и объектов управления).

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

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

Примечание к пункту «в»:

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

Как промежуточный итог:

Вполне логичные требования разработчиков к заказчикам системы в смысле: «Ребята, а вы опишите нам обычными словами, как вообще должна работать ваша система, что бы мы могли алгоритмизировать управленческие процессы…», наталкивается на глубокие вздохи, скрежет зубовный и завершается, как правило, посылкой разработчикам очередной редакции Боевого устава Сухопутных войск.

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

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

В итоге – разведчик не может передать «свои» данные общевойсковому командиру, тот- артиллеристу и т.д.

Грубо говоря – деньги на ветер.

А может пойти по другому пути?

Так сказать «подняться над суетой»?

Попытаться сформулировать наиболее общие (единые для всех элементов системы управления, добычи данных и их реализации) информационные задачи? А в рамках этих задач создать единые (опять же – для всех!) форматы представления данных и способы их обработки и передачи. Несмотря на различные «подсистемы» и разницы в подходах к решению конкретных «расчетно-аналитических», «расчетно-информационных» задач у разных производителей?

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

В конечном счете, весь порядок работы командира и штаба (а также органов, добывающих информацию и элементов боевого порядка (средств) поражения, ее реализующих) можно свести к нескольким «большим» информационным (в полном смысле этого слова) задачам!

Напомню, что всего таких информационных задач (не путать с этапами работы командира и штаба!) – восемь:



Об этом я уже писал здесь:
http://dragon-first-ru.livejournal.com/ ... tml#cutid1
и здесь:
http://dragon-first-ru.livejournal.com/2011/07/26/

Но, как говаривали древние латиняне: «Repetitio est mater studiorum».

По-видимому, с одного раза усвоилось слабо.
Так вот.

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



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

Данная классификация не является жесткой (как по временным параметрам, так и по порядку выполнения), в отличии от периодов работы командира и штаба, изложенных в Боевом уставе и Наставлении по службе штабов.

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

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

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

Для примера рассмотрим с этой точки зрения содержание указанной информационной задачи:



А вот содержание информационной операции «1.1 Добывание данных обстановки»:
№ Наименование информационной операции

1.1.1 Данные о наземном противнике (из подсистемы разведки, в т.ч – с БЛА)
1.1.2 Данные о наземном противнике (из подсистемы о/в п)
1.1.3 Данные о наземном противнике(из подсистемы РВиА)
1.1.4 Данные о наземном противнике из вышестоящего штаба (подсистема КиШ)
1.1.5 Данные о противнике из взаимодействующих структур (ВДВ, ВВ, МЧС) (подсистема КиШ)
1.1.6 Данные о наземном противнике с самолетов ФА и вертолетов АА (из подсистемы УА)
1.1.7 Данные о воздушном противнике (воздушной обстановке, из подсистемы ПВО)
1.1.8 Данные о реальном состоянии местности
1.1.9 Данные о РХБ обстановке (из подсистемы УРХБз)
1.1.10 Данные о погоде (включая прогноз)
1.1.11 Данные о положении своих войск (подсистема управления нижестоящего органа управления)
1.1.12 Данные о состоянии своих войск (в том числе – об оценки боеспособности)
1.1.13 Данные о состоянии запасов МС своих войск
1.1.14 Данные об элементах социально-политической обстановки в районе боевых действий

И предполагаемое содержание пункта 1.1.1 «Данные о наземном противнике (из подсистемы разведки, в т.ч – с БЛА)»:
№ Наименование информационной функции

1.1.1.1 Данные о наземном противнике (подсистема разведки, – с БЛА РД рб омсбр)
1.1.1.2 Данные о наземном противнике (подсистема разведки – наземные РЛС РД)
1.1.1.3 Данные о наземном противнике (подсистема разведки – наземные ЛПР РД)
1.1.1.4 Данные о наземном противнике (подсистема разведки – визуальное обнаружение РД)
1.1.1.5 Данные о наземном противнике (подсистема разведки – подразделения РиРТР)
1.1.1.6 Данные о наземном противнике (другие данные из подсистемы разведки )
Другое – то что не учел.

Смею предположить, что перечень информационных процессов в составе каждой информационной задачи (процесса, операции и функции), во-первых, не является исчерпывающим и может быть в ходе работы дополнен любым информационным процессом из любой другой информационной задачи, а во-вторых, – голова у Вашего покорного слуги не является «Домом советов». Может и упустил чего-нибудь.

Остальные информационные задачи содержат в себе информационные процессы, определяющие их название.

Данный подход к классификации способов работы с информацией может быть применен к ЛЮБОМУ ВИДУ боевых действий, а также к любому способу ведения этих действий.

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

С этих позиций может быть проведены:

1. Оценка возможности автоматизации данной работы (при подготовке технического задания)
2. Оценки достигнутой степени автоматизации задачи, процесса и операции (в уже существующих системах).
3. Корректное сравнение эффективности работы автоматизированного способа управления с неавтоматизированным (ручным) способом при выполни однотипных задач (процессов, операций и функций), как при работе одиночного офицера штаба, так и группы, или всего органа управления в целом.

ВАЖНО: Основным критерием оценки преимущества автоматизированного способа управления должно являться достигаемое сокращение цикла боевого управления, точнее - его организационной части (желательно при условии повышения качества выполнения работ) по сравнению с неавтоматизированным способом.

В следующей части проведем анализ степени автоматизации, достигаемой при выполнении какой-либо функции (процесса, операции) одной из информационных задач.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:33

Комментарии:

vinfdsc
Jun. 21st, 2012 10:11 pm (UTC)
Правила оценки достоверности - это вторичные алгоритмы системы. Для начала достоверность можно не оценивать. Главное, попытаться отобразить нужную информацию. Тем более что оценка достоверности сама по себе является нетривиальной задачей и полагаться на автоматическое её решение командиру не следует.

Опять же, такая постановка задачи не имеет никакого отношения к тому, что хочет увидеть программист в ТЗ и справочной документации.

На самом деле это вообще всё программисту пофигу.
Ему надо записать всё, что вы сказали примерно так:
1. Имеется несколько видов источников информации, в том числе информация от соседних подразделений, развединформация
2. Для каждого подразделения имеются один или несколько источников некоторых из видов информации
3. Необходимо отображать эту информацию .... (так-то и так-то) ....
4. Источник информации даёт информацию пакетами данных, в том числе может транслировать источники других видов (соседнее подразделение допросило пленного).
5. Пакет данных может содержать подпакеты данных (например, пакет данных о намерениях войск и расположении армии содержит подпакеты о расположении некоторых частей)
6. Каждому виду источника информации, каждому источнику инфомрации, пакету и/или подпакету данных командиром может быть установлена нечёткая достоверность (вероятность того, что объект является намеренной дезинформацией с логическими связями с другими объектами)
7. Каждый вид информации может иметь свои данные по точности оценки расположения противника и его численности
8. Необходимо проводить анализ противоречивости и точности полученных данных (задание на исследование и прототипирование)

Вот по такому заданию уже более-менее ясно, что делать (в смысле дополнительных исследований).


lazy_sphinx
Jun. 22nd, 2012 06:45 am (UTC)
Это в случае если один программист пишет все и сразу. Никто же не мешает решать задачи "отображение" и "оценка достоверности информации" разными разработчиками на общей объектной модели.
И реальный обмен информацией я бы ниже уровнем опустил - в смысле вообще не заморачивался на идеологическом уровне каким образом данные передаются - решать это транспортными протоколами по идеологии репликации, например - если пытаться строить распределенную систему. Там в общем-то не такие уж и мешки в смысле объемов обмена данными будут - все-таки командира взвода не особенно интересует обстановка в полосе другого полка, а штабы без связи все равно работать не в состоянии - так что на достаточную пропускную способность их каналов можно рассчитывать.
Оно, конечно, не так экономно получится в смысле трафика как в случае маршрутизации завязанной на осознанное обращение данных, но зато неизмеримо проще в проектировании и в случае дальнейшего расширения - вам не надо будет для каждой пары "источник сведений - обработчик" прописывать способы обработки.


vinfdsc
Jun. 22nd, 2012 08:27 am (UTC)
> Никто же не мешает решать задачи "отображение" и "оценка достоверности информации" разными разработчиками

Программистам, которые выполняют задачу отображения ставится по этой задаче подзадача. Оценка достоверности - другая подзадача для другой группы. Хранение всего этого и передача - подзадача третьей группы.
Я написал общее задание, из которого уже можно выделять подзадачи.
А вот из вашей "объектной модели" выделять подзадачи не получится.

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

> вам не надо будет для каждой пары "источник сведений - обработчик" прописывать способы обработки.

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


vinfdsc
Jun. 21st, 2012 09:58 pm (UTC)
На самом деле то, что вы пишете, для программиста будет филькина грамота.

Что на самом деле нужно программисту:
1. Заснять на видео всю работу военного на учениях.
2. Если надо, самому съездить и посидеть в танке или где ещё, выполнить цикл типовых операций офицера. Неважно, что программист не кончал военных академий, если захотеть, пояснить что и как можно
3. Всё это переводится в алгоритм работы как ПРОЦЕСС.
4. Все эти процессы анализируются на предмет общности, причём общность там двоякая:
1) Общность в описании процесса (объекты, координаты, связи между объектами, видимость, свойства объектов и связи этих свойств и т.п.)
2) Общность, собственно, в самих процессах. Грубо говоря, подвозим продовольствие и подвозим бензин - процессы общные. Роем окопы в разных процессах - тоже процессы общные. Исследуем окопы противника - возможно, тоже общность (как минимум, есть некоторая предполагаемая линия окопов)

А всё, что вы пишете, к сожалению, программисту не нужно абсолютно.
Запутывает только. Точнее нужно, но подавать это надо в иной форме.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:41

АСУВ ЕСУ ТЗ
Jun. 22nd, 2012 at 7:03 PM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

(Часть 4)

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

Возьмем максимально модный сейчас у военных источник информации – беспилотный летательный аппарат (БЛА). Мы не будем вдаваться в его летно-технические данные (тип и мощность двигателя, удельная нагрузка на крыло, максимальная дальность и высота полета, полезная нагрузка, продолжительность нахождения в воздухе, показатели маневренности и т.д.). Естественно, что «чем лучше – тем лучше». Однако, все эти показатели с точки зрения прохождения информации для нас пока не столь важны.

Так же в стороне мы оставим вопрос управления собственно аппаратом в полете. Для нас пока тоже не принципиально – летает ли БЛА «самостоятельно» (т.е. по заранее заданной программе), или управляется оператором, а также садится на ВПП, или на парашюте.

Просто предположим, что у нас есть некий разведывательный аппарат с некими «средними» ЛТД, способный летать, вести видеосъемку и фотографировать «подстилающую поверхность». А также оснащенный средствами связи, позволяющими передавать полученную информацию на точку взлета (пункт управления полетом). Главное – что бы он это делал!

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

Итак, полетели?

Стоп!!!

Во-первых: в армии все делается по приказу (команде)! В том числе и полеты всех и всяческих летательных аппаратов.

Во-вторых: А куда, собственно лететь?

Естественно, на территорию, занятую противником, куда же еще?

Но возможности аппарата не безграничны и время облета им всей зоны детальной разведки бригады все-таки больше, чем «мгновенно». А в обороне, между прочим, эта зона (т.е. фронт обороны умноженный на максимальную дальность огня самого дальнобойного средства + 1/3 фронта зоны обороны в стороны соседей) может составлять 20 на 35-40 км.

Всего-то!

Для того, что бы полностью «накрыть» этот район фотоснимками поверхности размером 400 на 500 метров (200 000 кв м), сделанных с высоты полета в 200 м, понадобится сделать около 4000 (четырех тысяч!) снимков. Для этого БЛА должен пролететь по прямой (не считая виражей) около 1600 км.

При средней скорости 100 км/час продолжительность полета по всей зоне будет составлять (без перекрытия площади снимков) 16 часов.

Не многовато ли для темпов современного общевойскового боя?

Для справки:

Скорость, дальность и продолжительность полета имеющихся в РФ отечественных БЛА:

ОРЛАН-10
ZALA 421-16
ЭЛЕРОН-10
ZALA 421-08
ЭЛЕРОН-3

Продолжительность полета
18
4; 8
3,0
1,5
2,0

Дальность полета, км
1400
520;1040
180
105
140

Скорость, км/ч
75–170
130–200
60–120
65–130
70–130


Подробнее о ТТХ и проблемах наших беспилотников здесь:

http://nvo.ng.ru/armament/2012-03-02/1_ ... tniki.html

Поэтому при подготовке обороны существует такое понятие как «направление сосредоточения основных усилий» (НСОУ).
Вопреки расхожему мнению, «направление» в данном случае, – это отнюдь не «тонкая красная линия», а площадная фигура! Иногда достаточно причудливой геометрической формы. Ее границы директивно определяет командиру бригады старший начальник в своем боевом распоряжении (боевом приказе). В этих границах командир при принятии решения сосредотачивает основную часть своих сил и средств, и способов их воздействия на противника. А начальник разведки бригады – основные усилия подчиненных ему сил и средств разведки. Как правило, эта зона может составлять от 1/4 до 1/3 всей площади детальной разведки бригады.

Но как об этом узнает командир разведывательного органа (командир разведвзвода разведывательной роты разведывательного батальона бригады), на вооружении которого состоит наш БЛА? Другими словами: как информация о границах направления сосредоточения основных усилий бригады дойдет до исполнителя?

И вот тут мы переходим в область решения информационных задач.

Передача данной информации относится к информационной задаче номер 3, «Доведение боевых задач», которая включает в себя следующие информационные процессы:



Самым простым (и наиболее наглядным) способом постановки задач является передача с пункта управления объекту управления (в данном случае – командиру разведывательного органа) электронного файла графической обстановки с отображением предполагаемого района полета, вписанного в ту самую геометрическую фигуру, обозначающую НСОУ:



А откуда все это берется?

Для создания такого файла начальник разведки бригады (если он ставит задачу командиру разведывательного органа напрямую, минуя его непосредственных начальников) в своей подсистеме разведки должен:

1. Получить от начальника штаба указания об организации разведки, а от командира бригады - соответствующую графическую информацию (подсистема командира и штаба) о начертании разграничительных линий, района (направления) СОУ и положении своих войск в масштабе 1:100 000. А это – выполнение информационных процессов 1.2 «Сбор данных обстановки» и 1.7 «Отображение данных обстановки» в ходе реализации информационной задачи номер 1 «Непрерывная работа с данными обстановки».

2. Привести полученные графическую информацию базовому масштабу своей рабочей карты (1:50 000) (выполнение информационного процесса 1.3 «Обработка данных обстановки» и отобразить ее на экране своего автоматизированного рабочего места).

3. Оценить площадь НСОУ и положение своих войск, в том числе местоположение БЛА (информационный процесс 1.4 Изучение данных обстановки той же информационной задачи)

4. Принять решение на организацию разведки (выполнение второй информационной задачи «Выработка решения» в полном объеме), в том числе – определить порядок и сроки использования БЛА (причем не одного, а всех, имеющихся в бригаде).

5. Отобразить поверх обстановки, полученной от командира, свое решение на организацию разведки и утвердить его у НШ бригады. Элементом этого решения и будет район и время полета нашего конкретного БЛА, который на рисунке отображен красным пунктиром с желтой подтушевкой, а также порядок и сроки доклада полученных результатов. (выполнение информационного процесса 1.7 «Отображение данных обстановки»).

6. Передать выработанную информацию исполнителям и…

7. … получить от них сначала квитанции с подтверждением, а затем – решения подчиненных на применение БЛА (полетные задания) и утвердить их, то есть выполнить два вышеуказанных информационных процесса информационной задачи номер 3 «Доведение боевых задач».

А что делает, получив задачу на использование БЛА, командир разведывательного органа?

Порядок действий и, соответственно, протекание информационных процессов у него почти такой же.

Отображает. Уясняет. Оценивает обстановку. Принимает решение. Отображает принятое решение (полетное задание) на электронной карте своего АРМа. Отправляет начальнику разведки на утверждение. Получает утвержденный вариант.

Примерно вот в таком виде:



Полетели? А вот вам и "индейское жилище", ребята!

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

Это ЕС-1856, установленный на бронеобъекте:


Работает этот девайс на ОС МСВС и именно на него придет задача на использование БЛА


….а также ноутбук фирмы «Панасоник», который используется для составления полетного задания и управления БЛА в полете. Операционная система – небезызвестный «Windows-XP» (ТМ):


Как Вы, наверное, уже догадались, перенос графического изображения района полета с одной машины на другую выполняется не автоматически, а терпеливыми ручками «ст.л-та В.Петрова» - командира разведывательного органа.
Как, впрочем и обратный перенос полетного задания с «Панасоника» на ЕС-1866. Как вы полагаете, такая работа сильно ускоряет процесс подготовки полета?

Правда, есть еще один вариант организации разведки с использованием БЛА, точнее – тактический прием втирания очков большому начальству, который был «блестяще» продемонстрирован создателями БЛА на одном из учений с 5 омсбр (на фото слева). Это развертывание пункта управления полетом БЛА (и соответствующих средств его обеспечения) непосредственно в штабной машине командира бригады. То есть – в святая святых командного пункта – в центре боевого управления. При этом, информация, необходимая для формирования полетного задания доводится лично командиром бригады оператору БЛА. С помощью тычка указки, или просто пальцем в экран. А рабочие материалы съемки при таком «совместном» размещении средств управления и разведки сразу докладываются (показываются) командиру.
Разумеетс - с экрана машины, с которой происходит управление полетом.

Это, наверное, сделано для того, что бы противник не «заморачивался» и по результатам своей радио и радиотехнической разведки сразу грохнул бы сразу и пункт управления бригады пункт управления БЛА .

Идем дальше.

В назначенный час БЛА все же взлетит и начнет "качать" информацию, интересующую начальника разведки. Естественно, информация эта пойдет на комп фирмы «Панасоник»!

То есть, для того что бы получать информацию в виде графического (фото и видео) изображения подстилающей поверхности в режиме реального времени у начальника разведки есть всего один выход:

Поставить себе на пункт управления такой «Панасоник», отобрав его у командира разведывательного дозора.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:50

АСУВ ЕСУ ТЗ Часть 5
Jun. 30th, 2012 at 8:49 PM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

(Часть 5)

Кстати, уважаемые читатели, а вы не задумывались над вопросом: в каком виде начальник разведки должен получать информацию от разведывательного дозора, оснащенного техническими средствами разведки (БЛА, радиолокационные станции, лазерные дальномеры)?

Полагаю, что к такой информации можно применить, как минимум, следующие требования:
Первое: информация об обнаруженных объектах должна содержать в себе их координаты, желательно - со стрельбовой точностью (плюс-минус 25 метров).

Второе: информация об объекте должна содержать фактическое время его обнаружения.

Третье: информация об объекте должна четко идентифицировать обнаруженный объект (танк, САУ, автомобиль, группа пехоты и т.д).

Кроме того, если объект движется, то крайне желательно иметь информацию о направлении (азимуте) и скорости его движения.

БЛА тактического назначения, «состыкованные» с ЕСУ ТЗ, передают на пункт управления полетом информацию о подстилающей поверхности в формате видеоизображения. Это, как правило, позволяет лишь приблизительно оценить то, что «увидел» аппарат. При попытке сделать стоп-кадры самых «вкусных» фрагментов видеоизображения, они, как правило, получаются размытыми и не дают возможности с достаточной достоверностью выполнить первичную идентификацию обнаруженного объекта. Получить стрельбовую точность координат обнаруженных объектов по видеоизображению тоже достаточно затруднительно. При таком способе ошибки при могут достигать 150-500 метров (в зависимости от высоты и скорости полета БЛА, а также от углов крена и тангажа).

Данные проблемы обусловлены следующими факторами:

1. Небольшая высота полета БЛА, используемых в тактическом звене.
2. Относительно высокая скорость полета.
3. Низкое разрешение используемых средств ведения видеосъемки.
4. Отсутствие у малоразмерных БЛА систем стабилизации видеоизображения.
5. Слабая подготовка и отсутствие опыта у операторов БЛА (военнослужащие срочной службы со сроком призыва 1 год).

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

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

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

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


В данном случае использован космический снимок, размещенный на картах Гугл здесь:
https://maps.google.ru/maps/myplaces?ll ... 0&t=k&z=18

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

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

Для справки:

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

В программном обеспечении практически всех систем управления БЛА имеется такая возможность. То есть, снимок с учетом направления и высоты полета, угла тангажа и крена, привязывается и отображается поверх электронной карты без каких –либо серьезных проблем.

Выглядит это примерно так:


Казалось бы, - остается только отобразить полученную информацию тактическими знаками вот так:


...и передать ее в подсистему командира и штаба для оценки и принятия решения.
Но нет.

Системы управления БЛА, как правило не предусматривают перевод полученной фото и видеоинформации в тактические знаки. А если предусматривают, то форматы отображения тактических знаков в их программах не совместимы с форматами отображения этих знаков в графическом интерфейсе ЕСУ ТЗ. То есть, даже если мы на компьютере, котрый управляет полетом БЛА отобразим тактическими знаками обстановку поверх ортотрансформированного фотоизображения, то передать такую обстановку в подсистему командира и штаба (или подситему разведки) будет невозможно.

Короче. Для того, что информация на экране начальника разведки приобрела вот такой вид:


…. в подсистему командира и штаба необходимо передать сами аэрофотоснимки ..!

Однако, в принятом в ЕСУ ТЗ формате данных (которые можно передать из системы управления БЛА в подсистему командира и штаба вместе со снимком), присутствует только одна(!) точка привязки (координат снимка). Эта точка - геометрический центр аэрофотоснимка.

То есть, в этом формате не учитываются ни масштабные параметры самого снимка, ни направление полета БЛА (дирекционный угол оси снимка), не говоря уже об углах крена и тангажа.

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



Короче – достаточно приблизительно, если не сказать – вольно.

И, если с точечными объектами, (которые по случайности оказались в центре "картинки"), такая «вольность» еще простительна, то в случаях с объектами, которые расположены на периферии снимка, а также с линейными и площадными объектами ценность такой информации стремится… ну, в общем, вы сами знаете куда.

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

Как вариант: всю работу по переводу полученной от БЛА информации в привычные для общевойскового командира тактические знаки выполняет уже знакомый нам ст.лейтенант Петров, имея на коленках одновременно две ПЭВМ. Опять таки – вручную! С экрана на экран.
Примерно вот так:



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

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

Одновременно выскажу робкую надежду, что указанные недостатки будут критически осмыслены разработчиками ЕСУ ТЗ и БЛА, и сделанные по ним выводы смогут помочь улучшить соответствующее ПО, обеспечивающее процессы обработки и передачи информации.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 00:54

АСУВ ЕСУ ТЗ
Jul. 1st, 2012 at 7:31 PM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

(Часть 6)

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

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

Представим себе, что почитав мой блог, военные и разработчики системы сядут за один стол и потратят ДВА ДНЯ(!) на составление таких таблиц.

В результате они получат ИНСТРУМЕНТ, с помощью которого можно оценить достигнутую в системе степень автоматизации задач, процессов и операций.

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

Например, если из десяти операций, выполняемых в рамках одного информационного процесса, девять требуют применения ручного труда, то можно смело говорить о том, что такой процесс НЕАВТОРМАТИЗИРОВАН в достаточном объеме.

Далее. Можно также использовать модную сейчас в ВС РФ методику «рейтинговой оценки». То есть, присвоить каждой операции (при условии ее полной автоматизации) определенное количество баллов (в зависимости от ее важности).

Затем, провести анализ соответствия требованию «быстрее, чем вручную», при реализации данной операции и суммируя получившееся в результате аналитической оценки количество баллов, (которое должно соответствовать истинному положению автоматизации) сравнить максимальное количество баллов с реально набранным.

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

Полагаю, что рассмотренная выше операция 1.1.1.1 «Данные о наземном противнике (подсистема разведки, – с БЛА РД рб омсбр)» получила бы крайне невысокие баллы.

Таким образом, рассмотрев, проанализировав и критически оценив ВСЕ информационные операции, процессы и задачи во всех видах тактических действий, можно было бы сделать ОБЪЕКТИВНЫЕ выводы о степени автоматизации как системы управления в целом, так и по подсистемам, а также решаемым управленческим задачам.

Например: максимально возможное количество баллов при полной автоматизации задачи 3. «Доведение боевых задач» равно 500.

А достигнутая степень – составляет всего 250 баллов.

То есть достигнутая степень автоматизации составляет не более 50%.

Однако, вышеприведенная методика дает нам только количественный анализ.

А как насчет качества?

Цитирую уважаемого Николая Михайловича РАДЬКО - заместителя генерального директора ОАО «Концерн «Созвездие»:
Цитата:
В общей сложности Минобороны России сделало 105 замечаний (по результатам работы МВК в октябре-ноябре 2011 года – курсив мой – Д.П.) и выдало рекомендации по совершенствованию автоматизированной системы управления тактическим звеном. Нами был разработан план-график их устранения, который мы согласовали с Главным штабом Сухопутных войск. К устранению замечаний мы с кооперацией приступили с начала текущего года. В настоящий момент работа практически завершается.
(Газета «Связист» №5, май 2012г.)
Конец цитаты.

И это – после проведения Государственных испытаний! Не многовато ли, Николай Михайлович?

Я понимаю, - система сложная, но давайте рассмотрим хотя бы основные моменты, по которым к создаваемой вашим концерном системе высказывают претензии военные.

С целью посмотреть, что изменилось в аппаратно-программной части системы, Ваш покорный слуга внимательно изучил представленные на форуме «Технологии в машиностроении-2012 (проходящем в эти дни в подмосковном Жуковском), образцы командирских, командно-штабных и штабных машин, а также опробовал на стенде концерна «Созвездие» некоторые функции разработанного ПО.

Мнение мое сугубо субъективное.

Но, поверьте, - на выставке было с чем сравнивать!

Итак.
Дружественность интерфейса.

Как и в предыдущих версиях ПО «Созвездия-М», в представленной на выставке версии свойство большинства интерфейсов мягко говоря, не отвечает тому, что наши вероятные друзья понимают под термином «friendly interface».

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

Любимый мною значок командного пункта 5 омсбр был отображен по моей просьбе на электронной карте за 31 секунду. Что на целую секунду быстрее, чем в октябре 2011 года.

Прогресс, однако!

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

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

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

4. Использование в качестве картографической информации геоинформационной системы с функцией увеличения (уменьшения) детализации отображения земной поверхности в зависимости от увеличения (уменьшения) отображаемого масштаба топоосновы (по принципу реализованном в «Яндекс-картах» и «Google Maps») также невозможно. В системе используется морально устаревшая модификация ГИС «Интеграция» под ОС МСВС. Справедливости ради, стоит сказать, что разработкой ГИС-платформ «Созвездие» не занимается. Используют «то, что дают»!

5. Отсутствует функция отображения графической обстановки с использованием средств интерактивной доски (нанесение обстановки «от руки»), или хотя бы комплекса интерактивный экран+стилус.

6. Отсутствует возможность автоматической генерализации тактической обстановки.

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

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

Достаточно, или продолжать?

Уважаемые разработчики системы ЕСУ ТЗ!

Вы всерьез предлагаете пустить ЭТО в серию?

Кстати, тактическая обстановка на экране дисплея АРМ выглядит так:



Примечание: Уважаемые читатели, а также сотрудники компетентных органов! Полагаю необходимым заявить, что данная тактическая обстановка не имеет реальной основы и создана абсолютно произвольно,– то есть, не отражает реального (или планируемого) положения войск при проведении каких-либо мероприятий боевой, или оперативной подготовки, а также не привязана к местности. Для фотографии ее перенесли по моей просьбе на совершенно произвольный участок карты. Кроме того, отображаемая топооснова имеет масштаб 1:200 000 и не является секретной.

Что касается аппаратной части системы.

Начнем с малого. Есть в составе комплекса такой прибор - коммуникатор абонентский



Ввиду принципиального отсутствия на вооружении ВС РФ аналогичных приборов, сам по себе «девайс» очень неплохой. Как говорится, на безрыбье – и консервная банка – подводная лодка!

На экране можно увидеть свое положение только относительно координатной сетки. А не местных предметов (что было бы логичнее!). К сожалению, геоинформационная система, использующаяся в ЕСУ ТЗ, не предусматривает отображения местности на экранах таких вот коммуникаторов!

Этим прибором должны быть оснащены отдельные военнослужащие.

А что в плане оснащения командиров и штабов?
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Re: Автоматические системы управления боевыми действиями

Сообщение Andreas » 22 авг 2013, 01:00

АСУВ ЕСУ ТЗ
Jul. 2nd, 2012 at 11:18 AM

«ПОВТОРЕНИЕ ПРОЙДЕННОГО»
или марш по граблям

Самый близкий к солдату начальник – это сержант.

Командир отделения.

Передвигается данный товарищ по полю боя либо пешком, либо на БТР (БМП). Это его «личный транспорт», самое мощное огневое средство, пункт управления, узел связи и программно-технический комплекс «в одном флаконе».

Линейный БТР, на котором по замыслу создателей ЕСУ ТЗ, должен работать командир отделения, по своему внешнему виду мало чем отличается от обычного БТР-80. Поэтому в данном посте его фотографии не будет. Извините.

А что у этой машины внутри?

А то же, что и раньше: защищенный компьютер Питерской фирмы «РАМЭК» (Процессор Intel Core Duo LV – 1,66 ГГц, с оперативной памятью 512 Мбайт, видеокартой 128 Мбайт и дисплеем на 12,1 дюймов. Жесткий диск 40, 80, или 120 Гбайт)



Данный комп жестко закреплен в корпусе БТРа и не может быть использован как выносное рабочее место. Предполагается, что выходя из машины командир отделения берет с собой абонентский коммуникатор АК-3,5 (да, тот самый – без возможности увидеть карту) и носимую радиостанцию Р-168-0,5 УМ (0,1У (М) Е), которая работает, если мне не изменяет память, в частотном диапазоне от 44 до 56 МГц.

Из средств связи непосредственно на машине установлены два полукомплекта возимой УКВ радиостанции Р-168-25УЕ-2 (30-108 МГц, максимальная дальность связи до 17 км).

Вот ссылка на ТТХ этой станции на сайте производителя:
http://www.radiozavod.ru/production/4/

Для обеспечения связи внутри БТРа смонтирован комплект аппаратуры внутренней связи и коммутации и управления (АВСКУ), а также аппаратура передачи данных (АПД).

Да! Есть еще приемник, обеспечивающий поступление информации о геопространственном положении машины от сети ГЛОНАСС.

Это все.

На первый взгляд – вполне серьезная и современная машина. Для сержанта-«срочника» со сроком службы 1 год.

Но. Мы же с вами, уважаемые читатели, не срочники?

Давайте разберемся.

Командир отделения в ходе ведения боевых действий в большинстве случаев будет находиться ВНЕ МАШИНЫ. Как в обороне, так и в наступлении. А при передвижении войск, как правило, используется режим радиомолчания и большинство р/станций работают только на прием. Причем, для уровня командира мотострелкового отделения данное правило исключений не имеет. Поэтому варианты организации связи в ходе марша мы рассматривать не будем.

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

Итак.

В системе связи автоматизированной системы управления в ходе любого вида боевых действий будет циркулировать следующая информация:
1. Голосовая. Да, уважаемые читатели, командный голос в эфире пока никто не отменял.
2. Цифровая (пакетная) с графическими файлами тактической обстановки и разного рода текстовыми сообщениями.
3. Цифровая (пакетная) с геопространственной информацией о положении объектов, имеющих средства ГЛОНАСС-коммуникации.

Теперь попытаемся обеспечить командира (и его начальников) отделения всеми видами этой информации.

Итак.

Голосовая двухсторонняя связь командиру отделения со своим непосредственным начальником (командиром взвода) нужна? Безусловно.

Аналогичная связь с экипажем БТРа? Конечно.

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

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

Передавать свои геопространственные координаты командир отделения и его БТР для отображения их на карте старшего начальника будут? А как иначе старший начальник узнает где кто находится на поле боя? При этом командир взвода может выступать как ретранслятором таких данных, так и только потребителем. Например, если в такую радиосеть объединены все машины и все командиры отделений в роте (около 20 объектов).

И здесь без отдельной радиосети не обойтись. Обозначаем ее голубыми стрелками с цифрой 3.



Читатель спросит: а почему бы не использовать для передачи всех этих видов информации одну радиосеть?

А потому, что скорость информационного обмена в радиосетях УКВ диапазона ограничена максимальным значениями 1,2 – 16 кбит/с. И если уж использовать радиосеть для управления в бою, то реально можно «гонять» в такой сети только один вид информации.

Или «цифру».
Или «голос».

Одновременно? Не получится! Ибо аппаратура передачи данных устроена таким образом, что если уж она поставила на передачу какую-нибудь цифровую информацию - то хоть голос сорви, но до тех пор пока радиостанция ее не передаст - никто из абонентов радиосети Вас не услышит.

Кроме того. Практика показала, что для более-менее приемлемого отображения на электронной карте всех подвижных объектов, например, мотострелкового батальона (около 50 машин с учетом средств усиления), данные о положении каждой машины надо передавать с периодичностью 1 раз в одну минуту. При этом, для передачи такой информации по УКВ каналу необходимо выделять отдельную частоту (радиосеть). Использование одной частоты одновременно для передачи и тактической и геопространственной информации приведет к тому, что абоненты этой сети в приемлемые сроки не получат ни того ни другого.

Однако, радиосредства, установленные на данной машине, обеспечивают всего лишь ДВА постоянно действующих радиоканала.
Вместо необходимых (как минимум) трех.

Кстати, про то, как будет обеспечиваться радиосвязь с отдельными солдатами, я уже молчу. Потому, что если включить рядовых бойцов в голосовую радиосеть (пусть даже на правах «слушателей»), то количество абонентов в такой сети превысит все разумные пределы.

Естественно, что ни о какой видеоконференцсвязи с отдельным солдатом на стыке двух фронтов (о которой так долго говорили большевики мечтают наши генералы), говорить уже не приходится.
"Всё будет так, как мы хотим. На случай разных бед, У нас есть пулемёт Максим, У них Максима нет"
Hilaire Belloc, "The Modern Traveller" (C)
Аватара пользователя
Andreas
 
Сообщения: 10965
Зарегистрирован: 22 май 2012, 16:31

Пред.След.

Вернуться в Новинки военной техники

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3