Наш паровоз вперед летит, в коммуне остановка

Иного нет у нас пути, в руках у нас винтовка

НЛО, февраль 2014
	Внимание, анонимный донос:
	«ГОСТ 28147-89 Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования». В 1994 г. описание алгоритма ГОСТ 28147-89 было переведено на английский язык и опубликовано.

По материалам интернета

Благодарности:

dragon_first_ru Отличнейшая серия статей о ВС и автоматизации управления войсками

http://dragon-first-ru.livejournal.com/30167.html#comments

Иванов Василий : GIStechnik - всё о ГИС и их применении

 

general-skokov  ВРИО Главнокомандующего Сухопутными войсками генерал-лейтенант С.Скоков « 30 » ноября 2010 года: Доклад для НГШ

 

Концерн «Созвездие»

 

И многие другие, участвовавшие в обсуждении статей dragon_first_ru?, их фото, видео и вести с «полей».

 

Какой должна быть АСУВ ТЗУ?

Обсуждение современных требований к АСУ, полемика, дан обзор ГИС, приведено ТЗ

Замысел:

Реализация:

 

Полемические заметки о проблемах АСУ войсками:

alex_the_drug

Jul. 20th, 2012 07:13 am (UTC)

ПО моему скромному мнению проблемы носят системный характер и не изменились со времен СССР:
1) есть заказчик, который не знает, чего хочет

НЛО: Неверно, обобщенное понятие «заказчик» состоит из конкретных людей, а каждый конкретный человек у заказчика знает, чего ОН хочет. Причем, начальник хочет (делайте что хотите, чтоб мне ничего делать не надо было) совсем не то, что пишет разработчик, а его подчиненный, который пишет ТЗ, хочет того, чего, как он думает, хочет будущий пользователь этой системы, а пользователь не хочет ничего, что будет его напрягать.

Следствие: ТЗ пишется под «заказ». Каков заказ – такое и ТЗ. И цели у такого  ТЗ могут быть совершенно не из области потребностей АСУВ.

Следствие из следствия: Разработку ТЗ должны осуществлять заинтересованные в конечном результате (ну настоящие военные) и  не зависящие от конечного результата конкретного исполнителя – разработчика и его связей со своим начальником.

Замечание к следствию – никому не нужен неуправляемый представитель заказчика.

Последствия: Любое прибыльное дело выводится из под контроля МО и переводится в частные руки. Ничего личного – только бизнес.

 При ГВТУ ГШ существовал центр "оцифровки", который наш милейший министр посчитал "малоэффективным" с точки зрения привнесения прибыли. Центр был сначала раскулачен, а затем и исключен со всеми вытекающими. Но в условиях рыночной экономики его уже гражданское руководство быстро смекнуло, что к чему и начало ПРОДАВАТЬ свою продукцию (электронные карты) кому бы Вы думали? Правильно! Своему бывшему "сюзерену" - сиречь МО. По очень нехилым ценам. Стоимость оцифровки ОДНОГО листа 50 000 подскочило с 5000 рублей до 45 000 рубликов.
2) есть исполнитель, который по идее может сделать, но не понимает, что от него нужно

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

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

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

Замечание к следствию: да где же взять такие деньги, чтобы можно было их просто выбросить?

Последствия: Ну, вы сами формулируете

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

При этом прямой вины чьей либо стороны здесь нет - военные действительно не могут сформулировать требования, т.к. они требуют проведения исследовательских работ и попросту на данный момент неизвестны. На мой взгляд решением является:
1) создание военного органа по типу DARPA, которое будет вырабатывать требования, стандарты и координировать работы в развитии АСУ ВС. При этом оно должно выступать только в роли заказчика и приемщика, самостоятельно должно проводить только НИОКР в определенном объеме - ровно настолько, чтобы могли определить те самые требования и стандарты, но чтобы много денег не могли распилить.

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

Такой организацией д.б. Концерн «Созвездие»
3) достаточно большое число мелких субподрядчиков, которые смогут выполнить и НИОКР, мелкое производство. Здесь контроль за расходованием денежных средств осуществляется за счет конкуренции. Также конкуренция позволить повысить качество продукции.

Несмотря на то, что рынок военной техники закрыт и специфичен, его можно сделать конкурентным за счет создания открытых стандартов и четких ТЗ. В этом случае ТЗ должно формироваться без привязки к предметной области (это как?), а носить абстрактный характер, в виде типового модуля или кирпичика, решающего типовую задачу. А из этих кирпичиков уже системный интегратор будет собирать воедино систему.
Здесь нужно политическая воля на организацию. Ибо финансовые интересы тут огромные. Фигура, принимающая такое решение, должна обладать огромным влиянием. Это позволит решить проблему из п.2.
Также необходимо проработать концепцию учебно-тренажерных комплексов, симулирующих реальные боевые действия с высокой степенью достоверности. И организовать постоянные учебные бои, в ходе которых военные будут давать оценку элементам АСУ. Музыкальный критик может и не суметь сыграть Баха, но оценить творчество композитора он сможет без проблем. Так и здесь - капитан вам не сможет сформулировать, что ему надо от АСУ. Но когда у него будет боевая задача и нужно будет ее выполнить с помощью этой АСУ - после завершения учений он вам точно скажет, что было не так, а что ему нужно. Таким образом можно будет решить проблему из п.1
Хотя, конечно, все это имхо.

Виктор Мураховский

May. 28th, 2012 02:47 pm (UTC)

Дмитрий Николаевич, спасибо! Очень хороший обзор. Я бы уточнил, что в настоящее время системы и средства связи ВС США полным ходом переводятся на стандарты JTRS, что позволяет FBCB2 опираться на бесшовную, гибкую, широкодиапазонную (2 МГц – 2 ГГц), устойчивую систему связи и навигации, с выходом на транспортные каналы глобальной информационной сети ВС США. Ну и нельзя не упомянуть потихоньку развертываемую тактическую информационную сеть WIN-T, которая как раз предназначена для обеспечения АСУВ в зоне ответственности армейского корпуса вплоть до батальона: «The WIN-T network provides command, control, communications, computers, intelligence, surveillance and reconnaissance (C4ISR) support capabilities that are mobile, secure, survivable, seamless, and capable of supporting multimedia tactical information systems within the warfighters' battlespace».

dragon_first_ru

May. 28th, 2012 03:16 pm (UTC)

Спасибо, Виктор Иванович! Я в курсе. Все расскажем, это только начало. Про связь и ПО и перспективы развития - будет продолжение.

Виктор Мураховский

May. 28th, 2012 06:14 pm (UTC)

Не сомневаюсь, что вы в курсе :)
Просил бы во второй (или какой другой) части рассказать немножко о FBCB2-JCR, ее предполагаемой интеграции в ABCS и LandWarnet.
Очень интересна тема унификации протоколов национальных АСУВ посредством Extensible Battle Management Language.
Если у вас хватит сил и желания, просил бы затронуть вопрос автоматизации средств добычи, методов обработки и порядка распределения развединформации (DCGS) в АСУВ: судя по всему, это первый "интеллектуальный" элемент оперативно-стратегических систем АСУВ, которые будут пытаться внедрить в тактическое звено.
Извините великодушно, невольно нарисовал план-проспект на год вперед :)

dragon_first_ru

May. 28th, 2012 06:37 pm (UTC)

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

chzhungahora

Nov. 30th, 2010 10:08 am (UTC)

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

dragon_first_ru

Nov. 30th, 2010 10:33 am (UTC)

Возможно, что я зря не уточнил. "Склеенный" район является в формате *.мар ВЕКТОРНЫМ! Отдельный лист карты формата *SXF масштаба 50 000 (также векторный) весит от 1, 5 до 2,5 мегабайт (в зависимости от местности - в горах - больше, на равнине - меньше).

Можно, конечно, заложить в каждый АРМ системы набор листов (файлов) топоосновы различного масштаба и рассылать только список номенклатуры - типа "сами пусть район клеют". Но во-первых: это создаст вероятность ошибки при создании района, во-вторых увеличит риск попадания в руки противника ПОЛНОЙ базы даных секретных карт. А в-третьих- процесс создания района работ в используемой в войсках программе достаточно сложен. Командир взвода (сержант) может с ним и не справиться.

chzhungahora

Nov. 30th, 2010 11:02 am (UTC)

Нет, это я невнимательно читал. Конечно же, SXF - векторный формат.

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

 

dragon_first_ru

Nov. 30th, 2010 11:20 am (UTC)

Ответ на первое замечание. Я, возможно, уже устарел со своими взглядами, но память пока не отшибло напрочь. Кое-что помню. Так, например, лозунг "на чужой земле малой кровью". И чем он для нас обернулся. Лично мне ближе "Не нужен нам берег турецкий..."

При ГВТУ ГШ существовал центр "оцифровки", который наш милейший министр посчитал "малоэффективным" с точки зрения привнесения прибыли. Центр был сначала раскулачен, а затем и исключен со всеми вытекающими. Но в условиях рыночной экономики его уже гражданское руководство быстро смекнуло, что к чему и начало ПРОДАВАТЬ свою продукцию (электронные карты) кому бы Вы думали? Правильно! Своему бывшему "сюзерену" - сиречь МО. По очень нехилым ценам. Стоимость оцифровки ОДНОГО листа 50 000 подскочило с 5000 рублей до 45 000 рубликов. Нормально так?

 

Отдельные вырезки из статей:

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

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

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

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

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

Выглядеть это должно следующим образом (Рис. 6):

Рис. 6. Организация многопользовательского доступа к файлу электронной карты

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

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

 При этом, отработанное в полном объеме графическое решение командира бригады в обороне может насчитывать от 1500 до 2500 тактических знаков (объектов). Если считать,  что на один знак (объект) будет затрачено в среднем 30 секунд, то минимальное общее время нанесения решения на электронную карту будет занимать 12,5 часов (без учета времени привязки знаков к местности). «Многовато будет, однако»!

Что конкретно представляют собой файлы электронных карт, используемые в настоящее время в ВС РФ? В чем их особенность и отличие от известных всем Google и Яндекс-карт?  Дело в том, что файлы электронных карт геоинформационной системы  "Карта 2005" формата *.SXF, принятые на снабжение Вооруженных Сил РФ (приказ Министра обороны от 15 июля 2009 года РФ N 722) являются точными копиями их бумажных собратьев – топографических карт издания Генерального штаба. Как по номенклатуре и масштабу, так и по степени детализации отображаемых объектов, а также году издания (обновления).

То есть, если на военной электронной карте масштаба, например, 1 : 500 000, некий город отображен оранжевым многоугольником с тонкой  черной окантовкой, то при увеличении масштаба (приближении объекта путем простой прокрутки колесика «мыши») этот многоугольник будет просто увеличиваться в размерах. Как, впрочем, и все остальные объекты карты (дороги, надписи и т.д.). Без детализации кварталов, улиц и домов, как это реализовано в упомянутых Google, Яндекс и им подобных «гражданских» электронных картах.

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

А подразделения? От КП бригады до самого удаленного КНП батальона (дивизиона) в районе сосредоточения бригады может быть и 25 и 30 километров. Объем файла района (*.map) масштаба 50 000, состоящего всего из 8 листов, колеблется от 10 до 16 мегабайт.

 

dragon_first_ru

Dec. 4th, 2010 12:37 pm (UTC)

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

Правда?
А я не знал! :-)

"Подписи "1 мсо" и тп должны ставиться автоматически"

Программку напишете?

dragon_first_ru

Dec. 6th, 2010 05:15 pm (UTC)

Второго человека спрашиваю:
Программу напишете? С привязкой объектов к базе данных? С таким расчетом, что бы вход в базу из основного окна програмы осуществлялся не более одной секунды, а выбор объекта - не более трех?

vinfdsc

Dec. 8th, 2010 06:37 pm (UTC)

> Программу напишете?

Деньги дадите? :) (выделено мной)

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

 

toropyggka

Feb. 5th, 2011 05:02 pm (UTC)

Я только начла читать весь этот ужас, поэтому с запаздыванием.

А где основные разработчики? Почему вдруг возникает вопрос с программированием?
У меня навскиду возникает большой вопрос: не знаю, как остальным, но рисовать ТАКОЕ от руки - ужасно. Нужна библиотека графических примитивов ( пользователи Фотошопов и 3Д Максов меня поймут). Имеем готовый примитив - МСБ в обороне - с гребешками взодов, с флажочком командира и проч.
Таких знаков, кстати, не очень много, набор тактических элементов на рабочей карте командира не слигком велик и они все формализуемы; их можно группировать по типам, объектам и проч.
Очень логично взять такой знак, перетянуть на карту, масштабировать и все. Секунд пять макисмум.

 

de_bugging

Dec. 5th, 2010 07:19 am (UTC)

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

 

dragon_first_ru

Dec. 5th, 2010 09:10 am (UTC)

На мой взгляд, программа должна предоставлять некий СПЕКТР ВОЗМОЖНОСТЕЙ. Захочет командир РУКОВОДИТЬ - его право. Но, как показывает практика, - основную часть времени при определении замысла с помощью графического редактора (т.е. тактическими знаками и руками операторов) занимает не их нанесение, а корректировка, так-как командир почти всегда недоволен, КАК они (операторы) поняли его мысль и воплотили ее на карте. Поэтому командиру, кроме этого способа, должна быть предоставлена возможность рисовать самолично. Толпа "распознавателей" будет не нужна, поскольку на стадии определения замысла применяются простейшие и наиболее употребительные тактические знаки и символы. В достаточно ограниченном количестве. Распознавание их, как показывает практика, обычно не представляет проблемы.
"Чистка" карты от черновых каракулей командира (после дублирования их операторами) должна осуществляться в один прием. (1-2 секунды).

 

Ну и т.д.

 

Обзор отечественных ГИС военного назначения показывает, что среди всего их многообразия систем есть такие, например ГИС «Карта 2011», которые вполне могут удовлетворить большинству озвученных требований. Остается только удивляться, куда смотрит концерн «Созвездие».  

Интервью с МО Сердюковым на фоне аппаратуры КП южного округа

Промежуточные выводы и предложения:

1.       При всем многообразии «железа», ОС, СУБД, разработчиков и заказчиков, нет другой альтернативы, как делать что-то одно и для всех.

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

3.       Делать мы можем, хоть винтовки Мосина, хоть автоматы Калашникова, хоть АСУ ТЗУ.

4.       Есть определенный задел:

а) Есть выстраданное временем «железо» - типа ЕС-1866 и перспективы – тактические терминалы (типа ТТ), планшеты, смартфоны.

б) Есть выстраданная (не окончательно, детские болезни еще есть) ОС военного назначения – МСВС. Многопользовательская, многозадачная, защищенная, UNIX подобная.

в) Есть международные стандарты, например, для ГИС систем, Web сервисов, сетей

5.       Нужно разработать и опубликовать в Интернете открытое ТЗ, как совместный труд специалистов, по типу Википедии

6.       Обсудить, вылизать ТЗ и объявить открытый конкурс.

7.       Денег не давать, будут делать только те, кто сможет сделать за свои деньги или на голом энтузиазме.

8.       А на сладкое – приз 2 млн. международных денежных знаков, типа евро, только первым 3 победителям.

9.       А для военной тайны и для защиты от врага у нас есть ГОСТ 28147-89 Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования

 

Итак, например:

Тактико-техническое задание

Наименование: Графический редактор для нанесения и отображения тактической (специальной) информации

Критерий эффективности: Сокращение цикла боевого управления – минимизация времени «ручной» работы с картографической информацией (нанесение обстановки, масштабирование, генерализация и т.п.)

Описание объекта автоматизации:

Комплекты АРМ на базе ЭВМ TS Strong@Master 7020T (ЕС-1866) являются едиными для всех уровней управления звена «бригада-отделение (танк)» и могут быть смонтированы (развернуты) на полевых пунктах управления бригады (здание, палатка, заглубленный, или защищенный пункт управления), на любом транспортном средстве типа автомобиль, на бронеобъекте (танк, БМП, БРМ, БТР), а также на вертолете.

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

ПЭВМ серии ЕС-1866, работающих под операционной системой МСВС, с загруженными прикладными программами  военного назначения, аппаратура внутренней связи, коммутации и управления (АВСКУ) а также радиостанции  КВ, УКВ и СВЧ диапазонов.

Современные широко распространенные бытовые устройства:

Планшет типа Samsung GT-P7500 Galaxy Tab 10.1 16 Гб 3G Black.
Частота процессора: 1 ГГц, Операционная система: Android, Версия ОС: 3.0, Количество ядер: 2 шт, 3G
Экран:  Размер экрана: 10.1 " (дюйм), Тип экрана: LCD TFT, Разрешение: 1280x800 пикс.
Память:  Объём оперативной памяти (RAM): 1024 Мб, Flash накопитель: 16 Гб

GSM-смартфон (поддержка 3G опционально), на ОС Android,  80 МБ оперативной памяти, экран диагональю 3.2 дюйма и разрешением 240х400 точек, имеется поддержка micro-SD карт с объемом до 16 ГБ, аппарат оснащен батареей на 1200 мАч. Недорогой смартфон Galaxy Wave 525 оснащен тыловой трех мегапиксельной камерой способной снимать HD-видео, Bluetooth версии 3.0, aGPS, Wi-Fi 802.11 b/g/n и даже поддерживает технологию прямой передачи данных Wi-Fi Direct.

Карты и спутниковые снимки Гугла и Яндекса – web сервисы в открытой сети Интернет

Типовые задачи, использующие картографическую информацию:

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

выполнение измерений по карте, определение площади, длины, периметра, построение зон отсечения, ведение статистики по характеристикам объектов

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

переход от отдельных листов обменного формата к «сшитым» районам работ - часто их называют проектами, склейками, атласами электронных карт

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

выбор оптимальных (с разных точек зрения и по разным критериям) мест для размещения объектов

импорт данных из обменных форматов – SXF, DXF/DBF, MIF/MID, Shape, S57/S52, GRD, TIFF, PCX, BMP и других;

 

Тактико-технических требования:

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

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

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

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

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

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

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

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

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

Информация о положении своих объектов, оснащенных аппаратурой определения координат в системе GPS/ГЛОНАСС, должна автоматически отображалась бы на электронных картах заинтересованных лиц (по выбору (запросу), или постоянно).

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

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

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

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

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

 

Срок проведения работы: К юбилею А.П.Чехова

Содержание и форма представления результатов работы:

1.      Действующий макет, портированный на  ЕС-1866 с операционной системой МСВС 3.0, ТТ, планшет, смартфон.

2.      Техническая документация, согласно ГОСТ, включая описание алгоритмов, пакет программ, руководство пользователя и администратора.

3.      Методика проведения испытаний и контрольный пример

4.      Протоколы обмена данными и их спецификации.