Ликбез (АСУВ)
Продолжение статьи "Будущее в прошедшем времени"
«Ст 72. …управление должно быть непрерывным, и принятое решение должно с развитием боя все время дополняться и развиваться соответственно новым данным обстановки.»
Полевой устав РККА 1939 год.
Часть десятая. «Вверх по лестнице, ведущей вниз»
Итак. Чем больше разница в масштабах карты вышестоящего командира, и подчиненного, тем крупнее знаки на карте последнего, тем больше они закрывают собой топографическую основу и тем больше мешают принимать решение и его отображать.
Вывод № 1:
При отображении файла обстановки на крупномасштабной карте необходимо изменять БАЗОВЫЙ масштаб обстановки. То есть пропорционально уменьшать ВСЕ знаки (флажки-танки-пулеметы), в ней отображенные. До тех пор, пока видимый размер знака (треугольника, флажка) не приблизится на карте к размеру стандартного трафарета офицерской линейки.
Надеюсь, что уважаемые читатели помнят, что перенос обстановки с одного масштаба карты на другой, является в штабной работе самым трудоемким и непроизводительным процессом?
И делать это, уменьшая каждый знак по отдельности, - означает, по сути, ЗАНОВО наносить обстановку решения, на которую уже потрачено большое количество бесценного времени. С учетом того, что в файле решения командира бригады может насчитываться до полутора тысяч знаков, такая работа с использованием ПРИНЯТЫХ НА ВООРУЖЕНИЕ программ может занять от двух с половиной до трех с половиной часов.
Вывод № 2:
Данный процесс необходимо автоматизировать.
Но разработчики наших автоматизированных систем управления войсками про это то ли забыли, то ли им не напомнили об этом люди с широкими лампасами, заказывающие разработку систем.
То есть, некоторые попытки автоматизации изменения базового масштаба все же предпринимались. Однако, значки тактической обстановки упорно сопротивлялись попыткам разработчиков синхронно их уменьшить (без потери точности привязки к месту нанесения знака). На деле это выглядело так: флажки становились меньше не пропорционально увеличению масштаба карты, а как-то хаотично. Один значок увеличивался вдвое. Другой - вчетверо. Третий оставался прежнего размера. При попытке оператора АРМа внести в этот хаос какой-то порядок - система реагировала угрюмо и однозначно. Она просто зависала. Иногда с потерей данных.
Надеюсь, что уважаемые читатели понимают, к чему это может привести в боевой обстановке.
Создатели наших систем автоматизированного управления войсками (для оперативного и тактического уровней) регулярно участвуют в выставках, форумах и конференциях. Обычно это сопровождается показом возможностей продукции двух концернов - московского «Системпрома» и воронежского «Созвездия». Стенды компаний поражают участников подобных мероприятий красивым мерцанием экранов, обилием разных электронных штучек, а также многословными комментариями их представителей.
Если Вас, уважаемый читатель, волею судьбы занесет на такой форум, или выставку, то прежде чем восторгаться, - не поленитесь задать разработчикам обоих концернов один и тот же вопрос:
«Покажите, пожалуйста, как обстановка, разработанная на карте масштаба, например 200 000 (уровень оперативного командования), будет выглядеть на другой топооснове (карте командира бригады масштаба 50 000)? И, если это возможно - измените при этом базовый масштаб обстановки.»
Почему-то этот простой вопрос вызывает у представителей реакцию, сходную с реакцией их продукции при попытке выполнить эту невинную просьбу. Они ЗАВИСАЮТ!
В прошлой части статьи мы остановились на том, что наш командир батальона получил боевую задачу на переход к обороне и теперь, ему необходимо привести БАЗОВЫЙ масштаб обстановки в соответствие с используемой топографической основой.
Выглядит это примерно так (картинки кликабельны):
50 000
25 000
В дальнейшем командир батальона принимает и оформляет на карте свое решение.
Например:
25 000
Решение командира батальона подтенено оранжевым цветом
В дальнейшем комбат, не выезжая на КП бригады отправляет копию файла с решением командиру бригады. И может получить по средствам связи информацию от комбрига о рассмотрении решения (утверждено/не утверждено), - то есть получить этот же самый файл обстановки, но уже с соответствующей электронной подписью комбрига.
При этом, обмен информацией с вышестоящим штабом должен занимать минимум времени и трафика сети. В данном конкретном случае, файл решения командира батальона (вместе с обстановкой решения командира бригады) имеет общий объем всего 179 килобайт.
Для сравнения: файл документа формата WORD (*.doc) в котором я пишу эти строки, имеет объем около 448 килобайт. То есть практически в два с половиной раза больше.
Командир батальона опять же по средствам связи передает файл своего решения командирам подразделений, а те, в свою очередь, приведя базовый масштаб обстановки в соответствие СО СВОИМИ потребностями в масштабе карты, также принимают решения, докладывают его (в виде файлов) комбату и доводят до своих подчиненных.
10 000
Решение командира роты выделено малиновым цветом.
На уровне взводов процесс повторяется:
5 000
Решение командира взвода дано без выделения цветом
При этом командир всегда может изменить (уточнить) решение своего подчиненного как в момент утверждения, так и в ПРОЦЕСЕ ЕГО ВЫРАБОТКИ, даже находясь на каком-то удалении от ПУ подчиненного.
Каким образом это ДОЛЖНО реализоваться?
Командир работая в локальной сети со своими подчиненными может потребовать от них выложить файлы обстановки своих решений в сеть и организовать к этим файлам многопользовательский доступ.
В результате - он видит в реальном времени, как работают его подчиненные при нанесении обстановки, и может при необходимости внести коррективы, а подчиненные, в свою очередь, могут видеть обстановки друг-друга и при выработке своих решений учитывать не только полученную от комбата задачу, но и решения соседей. Так уже на этапе выработки решения могут закладываться ОСНОВЫ ВЗАИМОДЕЙСТВИЯ между подразделениями по времени, месту и решаемым задачам.
А как решения подчиненных отображается на картах (планах) вышестоящих командиров?
Об этом - в следующей части.
Продолжение следует