Проектировщик о продукции НПО ПРОГРЕСС...
Я говорю только о приоритетах в разработках, хочу понять в чем Ваша разработка уникальна, в чем ее новизна. ... Что касается архитектуры системы, включая БИУС - это 19 век

Это достаточно серьезное заявление. Можете ли Вы обосновать или более подробно раскрыть свою позицию?

to C4I

Уважаемый собеседник! Ваши 5 копеек тянут на золотой пятак. Вы абсолютно правы с Т-235ШП ошибочка вышла. Спасибо, что поправили и разнесли две разработки: АПД Т-237 (заказчик ГАБТУ) и АПД Т-237ШП, которую делал Пензенский филиал Атласа, по заказу НИВЦ АС. Что касается достать козырей и опубликовать фактики - к сожалению не получится. Документики тянут на гриф "СС" и несмотря на прошедшие годы первые отделы учреждений держателей "Акта и протоколов" - гриф не снизили.А что касается публичного раскрытия конкретики инновационных системотехнических решений ОКР "Полет-К" - извините время еще не пришло! Поэтому прошу меня не провоцировать к раскрытию замыслов главного конструктора АСУ "Полет-К". Он меня на это не благословлял. В АСУВ-строении ТЗУ еще только все начинается. Желающих спионерить чужие идеи - пруд-пруди. А системщики АСУ "Полет-К" еще не списаны и занимаются делом. Если Вам так все интересно можно ознакомиться с патентами на полезные модели и методы по тематике АСУ "Полет-К". Ваш сарказм по поводу разработки РКД на АРМ с использованием багетовских модулей не принимается. Предприятие параллельно разрабатывало два комплекта РКД не от хорошей жизни.Нужны были деньги - зарплата не выплачивалась по полгода. А.Е.Тюлин шел на различные хитрости,чтобы загнать ГК в рамки багетовских решений, но не тут-то было предприятие продолжало идти своим путем.К тому времени прошли апробацию действующие макеты АРМ, были созданы и испытаны АРМ для авиационных бортов. Впоследствии решения были спионерены хваленным ТРАНЗАС, другими фирмами от авиации. Вы намекаете на некоторые ошибки при проектировании с учетом примера по блокам питания. Этим направлением занимался очень уважаемый специалист - он справился со своей задачей.Допущенные просчеты были устранимы. Я даже не хочу их обсуждать.Были просчеты и покруче. Приведу пример.На одном из этапов специалисту разработчику протоколов пакетки было поручено верифицировать протоколы собственной разработки с реализованными в Софте. По факту проверки было установлено, что отв.исполнитель  своим решением исключил при задании на программирование протокол решающей обратной связи. Были и другие проколы при проектировании из области соглашательства под давлением Заказчика. К примеру - использование штатных АВСК вместо АВСКУ, которое было спроектировано, но так и не изготовлено по политическим причинам.Это подтверждает, что жизнь богаче любой ее модели.Я не удивлюсь если за ником С4I - прячется (А.Д., который продолжил свою деятельность в ЗАО "Информ-Связь"). Информацию о СЧГА и УСК можно найти в общевойсковой академии и 27 ЦНИИ МО. А лучше всего обратиться к минчанам в НПО "Агат", но лучше тогда искать китайский вариант их исполнения.

to ИнженерЯ

За представленную информацию огромный респект и уважуха!
Спасибо огромное! Буду осмысливать! Уже появились вопросы, например, как Вы собираетесь при организации единого навигационного пространства защищать его ресурсы? Может у Вас Софт поддерживает протокол типа "RADIUS AAA"? Или Вы используете, что-то из области БИЗКТ?

to Андрей
Цитата

"Это достаточно серьезное заявление. Можете ли Вы обосновать или более подробно раскрыть свою позицию?"

Уважаемый Андрей! Дело в том, что в целях решения, поставленных мне задач я занимаюсь проектированием систем реального времени. Проектируемая нашим коллективом автоматизированная система относится к классу роботизированных систем. БИУС Главным конструктором которого является уважаемый мной ИнженерЯ относится по ряду свойств к классу этих систем.Поэтому свой вывод о применяемых технологиях, архитектуре, массо-габаритных и функциональных характеристиках БИУС я сделал не только с учетом,представленных таблиц Главным конструктором, но и НИОКР заданных у нас, выполняемых в развитых странах, а также уже существующих изделий передовых стран.Например в классе БЛА различных классов.Могу только сказать, что в отечественной БИУС относительно зарубежных сохранен принцип двух уровней организации вычислительного процесса.Я имею ввиду, что на нижнем уровне предусмотрены сопроцессоры обработки потоков информации от сенсоров, а на втором уровне -центральный процессор под управлением ОС реального времени обеспечивает решение всех прикладных задач с учетом выполнения аппаратных прерываний и обслуживания потоков с сопроцессоров.Во всем остальном архитектуры отечественная и зарубежная расходятся. В первую очередь как по поддерживаемым интерфейсам, так и по использованию классов сопроцессоров.Например в зарубежных БИУС широко используются скалярные процессоры - заточенные под высокопроизводительную обработку определенного класса данных. Между прочим ИнженерЯ умолчал какая ОС реального времени используется в БИУС, какой движок СУБД реального времени они используют.Об отставании технологий я делаю вывод исходя из отсутствия упоминания ГК сведений об используемой платформе IDE, защищенного промежуточного программного обеспечения (Middelware), которое определяет не только состав поддерживаемых интерфейсов, но и применяемость открытых протоколов,а также высоко-интегрированных свободно распространяемых программно-аппаратных средств, например-автопилотов и т.п. За рубежом уже созданы БИУС, поддерживающие работу с датчиками (сенсорами) силовой установки, созданных с использованием нанотехнологий, компьютеров класса LHMBC, а также вычислительной среды, обеспечивающей поддержку описания и функционирования измерительных процессов и виртуальных приборов.ООО НПО "Прогресс" я настоятельно рекомендую двигаться к освоению новых вершин.

Э-Эх
Добрый вечер !
Был в командировке на ОАО ГРПЗ по изделию АБАК-РЛС1М
http://www.mriprogress.ru/_files/G3M.pdf
На п.40...

Неужели такого, скажем так, немощного процессора достаточно, чтобы вести работу оносвременно с 4-я видео потоками, плюс, как я понял, он отвечает за графическую оболочку?

Ответ.Конечно нет....умышленно не показан вот этот блок....
1.2.Встроенный в ЦБУН блок видеопроцессора (БВ-1):
Видеопроцессор типа Lynx3DM8+(SM722G8);
Поддержка LCD панелей с разрешениями 640x480, 800x600,1024x768,1280x1024 пикселей и разрядностью
цвета 9,12,18,24 бит;
Поддержка до 4 аналоговых видеокамер PAL/SECAM и NTSC с разрешением 720x576/720x504 и 25/30 кадров в секунду.....
С уважением, ИнженерЯ

Проектировщик

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

Что мы и реализовали в своих изделиях....и не только это...
....
Баллистический вычислитель 1В539М предназначен для сбора
информации от датчиков, обработки ее и вычисления углов прицеливания и деривации,кинематических и других угловых поправок (углов упреждения) при стрельбе из автоматической пушки и орудия - пусковой установки, а также настройки и контроля СУО при эксплуатации. При стрельбе УР также решает задачи выработки постоянных углов прицеливания (при стрельбе с превышением и без него) и упреждения или обеспечения
встреливания УР в поле управления.
В отличие от баллистического вычислителя 1В539,
входящего в состав СУО БМП-3, 1 В539М имеет большой схемотехнический потенциал и благодаря этому реализует полный стрельбовый алгоритм, позволивший учесть все
необходимые факторы стрельбы.....
Для резервирования баллистического вычислителя 1В539М возможно использование центрального блока управления и навигации изделия ГАЛС-Д3М, который имеет еще больший, по сравнению с существующим, как схемотехнический, так и программный потенциал. Вычислительное ядро ЦБУН содержит несколько одноплатных компьютеров с различными операционными системами. БИУС ГАЛС-Д3М без проблем может быть интегрирована в единый цифровой канал обмена (RS-485) не только автоматизированной системы управления огнем БТТ, но в автоматизированную систему связи (по RS-232C),
включая стабилизацию антенной системы перспективных спутниковых систем на борту ВВТ. Кроме того, БИУС имеет возможность работы по CAN шине с электронным блоком
управления (ЭБУ) двигателя – тем самым проводить автоматическую диагностику режимов работы двигателя ВВТ....
В добрый путь !
С уважением, ИнженерЯ
Да...еще не забывайте об обработке РЛС информации !!!!

Андрей Л.
на п.41.
Право Проектировщика заявлять о чем угодно....
Наши изделия открыты для осуждения...что в рамках открытого осуждения - нет проблем. Что в рамках закрытой информации....Вы уж извините.

Между прочим ИнженерЯ умолчал какая ОС реального времени используется в БИУС, какой движок СУБД реального времени они используют.Об отставании технологий я делаю вывод исходя из отсутствия упоминания ГК сведений об используемой платформе IDE, защищенного промежуточного программного обеспечения (Middelware), которое определяет не только состав поддерживаемых интерфейсов, но и применяемость открытых протоколов,а также высоко-интегрированных свободно распространяемых программно-аппаратных средств, например-автопилотов и т.п

А на каком основании я буду раскрывать Вам информацию ?
Раскрывать ОС..элементную базу (это запрещено тем же приказом МО РФ № 1555 для всех предприятий всех видов собственности)....
Проектировщик...
Анализ программ агентства по перспективным оборонным научно-исследовательским разработкам США (DARPA - Defense Advanced Research Projects Agency), показал повышенный интерес агентства к инновационным разработкам в области спутниковых инерциально-навигационных систем для вооружения и военной техники США (Program: All Source Positioning and Navigation (ASPN), Solicitation Number: DARPA-BAA-11-14).
Изделие “ГАЛС-Д2М-4” НПО ПРОГРЕСС решает не только инновационные задачи,обозначенные в программе ASPN агентства DARPA в области бесшовных навигационных решений для военных пользователей, но и реализует инновационный подход к архитектуре единого информационно-навигационного пространства для вооружения и военной техники
Вооруженных Сил Российской Федерации в т.ч. ПУ ПГРК - МБР....
Далее...
Проектировщик...
Без обид....Все Ваши "доказательства" по п.44 - это лишь Ваши догадки ...
В п.42

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

Вы имеете знания полученные в 16 ЦНИИС МО РФ...но это прошедшее время....мы работаем в настоящем с конкретными типами перспективных типов ВВТ. Я думаю что Вы меня поняли....

Проектировщик
на п. 43

Уже появились вопросы, например, как Вы собираетесь при организации единого навигационного пространства защищать его ресурсы? Может у Вас Софт поддерживает протокол типа "RADIUS AAA"? Или Вы используете, что-то из области БИЗКТ?

Мы специалисты в этом вопросе...т.к. большая часть сотрудников из ведущих ЦНИИ МО.....
Зачем я буду рассказывать на открытом форуме то что относится к нашим ноу-хау ?
Мы уже научили многие предприятия ОПК....Хватит...
Проектировщик....
А вот у меня к Вам вопрос...могли бы Вы привести ссылки на краткие описания российских изделий аналогичных нашим ?
Тем более, по БИУС (боевым) для Сухопутных войск Вооруженных Сил России (не ВМФ)...
Ну,например, как это краткое описание...
http://www.mriprogress.ru/_files/G100.pdf
Я думаю, Вы поймете о чем идет речь....

на п.44..

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

Нет слов ! Крутой вывод.
Проектировщик...
Опубликуйте ссылку на форум на конкретный тип вооружения и военной техники (например, Ми-28Т,Тауфун-У,БМП-3 и т.п.) где все описанное Вами реализовано....

to ИнженерЯ

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

С уважением Проектировщик.
P.S. Увидел! Увидел! Виртуальные приборы на борту. Теперь все прозрачно!

Проектировщик
на п.50...

Я Вам желаю не сдавать своих разумных конструкторских позиций и не уступать рынок БИУС другим пронырам.

Спасибо...
Спасибо за понимание...
С уважением, ИнженерЯ

ИнженерЯ своим постом 41 я не хотел рассматривать уязвимости или недостатки Ваших изделий, Вы, как ГК, о них знаете лучше, чем кто-либо другой...
Я хотел повернуть беседу в область перспективных направлений развития подобных изделий. Это можно сделать и не раскрывая грифованой информации по Вашим изделиям, достаточно, КАК МНЕ КАЖЕТСЯ, поставить Ваш вопрос поста 49 не так

Опубликуйте ссылку на форум на конкретный тип вооружения и военной техники (например, Ми-28Т,Тауфун-У,БМП-3 и т.п.) где все описанное Вами реализовано....

поскольку так развитие темы не имеет перспектив, а скажем:

Проектировщик:
Опубликуйте пожалуйста ссылки или назовите изделия, где все описанное Вами реализовано....

Это расширяет рамки анализа для Проектировщика и позволит и Вам, и посетителям посмотреть на аналоги, в которых реализована хотя бы часть характеристик, приведенных Проектировщиком в посте 44.

Вы со мной не согласны?

Андрей Л.
На.п.52
Согласен...
Однако, как я понял из п.50, Проектировщик будет занят...

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

С уважением, ИнженерЯ

to ИнженерЯ!

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

to ИнженерЯ!

Жду от Вас адрес временного почтового ящика! Когда через него получите программную архитектуру вычислительного ядра современной и перспективной АСУ сможете привязать к ней мои пояснения.

Проектировщик
на п.55
Уважаемый Проектировщик
Я выслал Вам свой электронный адрес...
С уважением, ИнженерЯ

Проектировщик - а что там какие то секретные данные или может остальные тоже могут хоть что-то увидеть?

И можете ли Вы здесь ответить на вопрос поста 52

Опубликуйте пожалуйста ссылки или назовите изделия, где все описанное Вами в посте 44 реализовано....

В свое время, 16 ЦНИИС имел огромный опыт по АСУВ и средствам связи ...служащие института (в основном это были старшие офицеры) имели не только большие вычислительные ресурсы....но и огромный межвидовой опыт, возможность работы с опытными образцами созданными по их ТЗ.
Созданные математические модели и программное обеспечение сотрудников 16 ЦНИИИС до сих пор актуальны и некоторые программные продуты стоят на вооружении....
Сравнительный анализ созданного программного обеспечения показывает, что созданное в 90-х годах оно (ПО) актуально еще сегодня и превосходит по многим показателям зарубежные модели, в т.ч. по расчету вероятностных моделей боевых действий с применением различных средств РЭБ и ЯО на различных носителях....
На мой взгляд, публикация математических моделей и принципов их построения, является не очень правильным шагом.
Одним из факторов является большое количество недобросовестных российских компаний, которые могут воспользоваться результатами работ большого числа разработчиков....
Именно из-за вышеназванного, был изъят весь тираж монографии и уничтожен...
Зачем учить конкурентов, которые потом выдают наши результаты за свои....

to Андрей Л.

Уважаемый собеседник!Дело в том, что в публичном доступе будут обсуждаться решения, которые могут быть реализованы третьей стороной с использованием идей, технологий и  изделий разработанных двумя другими сторонами в коммерческих целях.Поэтому давайте уважать друг-друга.Я принял решение раскрыть и обсудить некоторые выигрышные и уже,реализованные технологии исключительно для прменения в БИУС и навигационных системах, создаваемых заслуженным человеком - ИнженеромЯ, который занимается государственным делом в рамках частно-государственного партнерства.Кроме того область моих разработок гораздо шире и не пересекается с коммерческими интересами OOO НПО Прогресс. В большей мере это они могут заинтересоваться описываемыми мной разработками, или я их изделиями - если они будут доведены до необходимых ТТТ.

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

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

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

В связи с этим у меня вопрос - почему такую перспективную систему не вывели на гражданский рынок ведь для этого:
- был первый этап как раз в девяностых с требованиями диверсификации от предприятий ВПК - уж какой удобный момент, чтобы применить эти разработки в гражданском секторе и вывести свои предприятия и страну на мировой рынок высоких технологий, возможно и судя по всему и СУБД, и даже судя по всему в среде полноценного объектного программирования, а также в системах лингвистического анализа и распознавания;
- сейчас идет вторая волна, которая требует от предприятий перевода военных технологий в гражданский сектор - и... я не вижу на рынке перспективных российских СУБД, объектных сред и т.д.


Почему так происходит? Почему никто не пытается вывести свои системы не имеющие аналогов в мире на гражданский реально конкурентный рынок, а не кулуарный ГОЗ?

to ИнженерЯ!

Уважаемый инженерЯ! В Ваш адрес выслана схема программной архитектуры ядра вычислительной среды существующих и перспективных автоматизированных систем. При наложении этой программной архитектуры на ваши навигационную систему и БИУС Вы - действительно сможете обеспечить организацию единого информационно-навигационного пространства не только в рамках создаваемых Вашим предприятием систем, но и АСУВ в составе которых они будут использоваться. Разрабатываемые Вами изделия сразу приобретут свойства характерные системам функционирующим на сетецентрических принципах с сервисно-ориентированной архитектурой. Чуть позже я сброшу Вам близкий аналог к Вашей системе в котором частично уже реализованы некоторые компоненты ядра такой вычислительной среды. Ваши системы с такой вычислительной архитектурой сегодня нужны разработчикам АСУВ позарез. Получение навигационной информации пользователями в таких системах должно обеспечиваться по подписке на соответствующие сервисы. При этом должна обеспечиваться работа с сетевыми Государственными ресурсами ЦИМ и различными сетевыми ГИС с привязкой навигационной информации к данным ЦИМ на принципах  предоставления сервисов в реальном масштабе времени.Сегодня такая работа уже проводится в рамках партнерства Государства с частными компаниями. Что мне как разработчику АСУ еще нужно от Ваших систем. В первую очередь, чтобы Ваши программно-аппаратные навигационные средства и БИУС имели встроенных агентов, а каждому сенсору (датчику) присваивался -ID. Мониторинг изменения свойств контролируемых объектов, а также управление параметрами изделий должно осуществляться с использованием единой модели данных,а также на основе интерфейса отображения функциональной (топологической) схемы системы с вложенностью до датчика (сенсора) включительно. При этом для обмена данными по каналам связи должны использоваться технологии puch, ХМL, а также онтологии предметной области. В связи с тем, что на борту ЛА я увидел виртуальные приборы, скажу, что использование инструментальных средств типа LabVIEW является правильным, но не достаточным. Если на левой стороне схемы расположить,  Ваши блоки с внедренными агентами, поддерживающими международные стандарты открытой модели данных, Ваши системы смогут поддерживать режим динамической реконфигурации. А теперь представьте, что данные от Ваших систем в реальном масштабе времени в виде онтологий поступают и обрабатываются  в АСУВ, тренажерных комплексах и др. В первом случае на основе единичных данных можно автоматически с использованием сплайнов формировать элементы (яйца, пер.край, ХД и т.п.)оперативной обстановки, а во втором случае вместо виртуальной реальности, моделировать и управлять силами и средствами в объективной реальности. Вот когда можно по полной использовать разработки ТРАНЗАС с внедрением их в боевые системы. А пока уважаемый ИнженерЯ очень надеюсь на Ваш энтузиазм. И ждем от Вашего предприятия изделий с такими функциональными возможностями.
Теперь если Вы не возражаете можно перейти к анализу программно-аппаратных изделий. В части соответствия Ваших систем требованиям со стороны АСУВ нового облика ВС - оценку лучше Вас никто не сделает.

Проектировщик
Спасибо...архитектуру ядра вычислительной среды существующей и перспективной автоматизированной системы обеспечивающая сетецентрический принцип организации функционирования и боевого применения получил....
Да...Вы продвинулись далеко вперед....
Многое чего мы уже имеем сегодня, но сейчас мне необходимо время для того, чтобы я собрал совещание и детально обсудил Ваши реальные предложения c разработчиками ПО....
Я бы сказал так: работа не на один день.....
программно-аппаратные навигационные средства и БИУС имели встроенных агентов, а каждому сенсору (датчику) присваивался -ID
Откровенного говоря, я давненько думал об этом...вот как-то все руки не доходили, поэтому пока БИУС у нас "замкнутая",а не открытая платформа....и это не только у нас.
Я многие Ваши идеи понял.....
Еще раз спасибо....
MySQL имеет сертификат ФСТЭК №1319-1 и ОУД1....

MySQL

:) В сочетании с не имеющими аналогами в мире это звучит как шутка :)

Андрей Л.
Есть выбор (и Проектировщик их отобразил в своей архитектуре)....но есть и требования МО РФ по ПО...не мы их придумали...и требования из года в год - жесткие.....

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

Проектировщик

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

Да...мои ребята подтвердили Ваши слова....
Спасибо
С уважением,
ИнженерЯ

to ИнженерЯ!

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

Цитата "MySQL имеет сертификат ФСТЭК №1319-1 и ОУД1...."  . Пусть кто не знает поломает мозги! На самом деле все используемые нами программные и информационные технологии из состава вычислительного ядра сертифицируются под Гостайну, а  для применения в АСУ гражданского сектора еще и по требованиям ФСТЭК и ФСБ с учетом применения средств криптографии.

to ИнженерЯ

Мне кажется, что использование ряда высоко-интегрированных ЭРИ позволит Вам значительно снизить массо-габаритные характеристики ваших навигационных модулей, а также в значительной степени опционально прирастить их функциональные возможности, придать БИУС унифицированный характер для применения в ОВиВТ, робототехнике, автоматизированных системах различного назначения.

Проектровщик.
по п.67. что-то я расслабился в субботу...
Все понял....Согласен на 100%.
по п.68. Вообще-то...мы так и хотим, как Вы описываете (пока поляна не занята)....
Но..идет страшное копирование идей....
В то же время, Заказывающие управления МО РФ (в т.ч. ГРАУ и ГАБТУ) уже знакомы с нашим БИУС....и прописали наши ТТХ в ТТЗ некоторых перспективных изделиях....
В некоторых ВВТ мы будем единственными поставщиками....но ВЫ правы (!!!!!!) -  надо срочно идти на унификацию.....

Цитата "MySQL имеет сертификат ФСТЭК №1319-1 и ОУД1...." . Пусть кто не знает поломает мозги!

Ещё раз улыбнулся. Ну Вам там конечно виднее, но дело не в том имеет ли он сертификат ФСЭК а в том, что эта СУБД имеет ограниченную функциональность и по построению базы, и по работе с объектами, и по работе с большим объемом данных, и по обработке данных в реальном режиме времени.

И XML - я конечно понимаю, что это унифицированный формат, но надо же всё таки всё по назначению использовать. Операции чтения и записи самые трудоемкие по времени и ресурсам - XML содержит структуру требующую дополнительно минимум 20% информации, которая является не более чем идентифицирующей. А к ней нужно будет писать ещё интерпретатор или транслятор, или использовать существующие, огромной скоростью не отличающиеся.
Если речь идет о перекачке данных между системами, пр и этом нет критичности по времени передачи - то да, можно использовать, но господа - в реальном режиме времени???

Вы говорите, чтобы ИнженерЯ подумал над тем, чтобы датчикам и другим устройствам, с которых имеет смысл считывать данные присвоить ID. Каждое устройство, помимо ID имеет ещё ряд свойств и может выполнять события, которые можно инициировать или остановить - т.е. управлять этим устройством - т.е. рассматривать его как объект.
Хотите работать с объектом в реальном режиме времени? Тогда без объектов не обойтись - хотя можно их и имитировать, но это извращение уж простите. Есть большая разница в том, чтобы передать продуманную структуру объекта одним блоком, который ложиться и записывается сразу как объект или придумывать ещё цепь процедур, которые будут забирать поток информации и преобразовывать её в структуру - в реляционную или плоскую базу, а потом её же и собирать внутри АСУВ для взиуализации. С точки зрения сокращения времени воссоздание работы объекта собственными силами вряд ли выиграет по скорости работы у готового объекта. Ну а работу при таком двустороннем обмене данными через XML можно отнести к наиболее медленному виду.

Вы хотите, чтобы ИнженерЯ подумал над API к этим устройствам в соответствие с теми требованиями, которые Вы закладываете в свою АСУВ? Тогда Вам придется сделать открытую архитектуру передачи данных в систему, иначе остальные разработчики будут разрабатывать API несовместимые с Вашей системой и она сама по себе будет ограничивать развитие, средств связи, визуализации и дополнительных устройств контроля и управления в ВС.
Однако – если API будет работать не с объектами, то и это ограничит возможности устройств, иначе спецификации обмена придется постоянно корректировать и расширять.
Знаете зачем в СУБД появился Variant и зачем начали думать над неудобным промежуточным форматом передачи параметров массивами, затем таблицами – потому что они пытаются сделать передачу максимально унифицированной, даже в ущерб производительности и приблизить модель к объектной передаче.

ИнженерЯ
Андрей Л.
А вот что мы сегодня имеем на борту...скажем боевых российских вертолетов ???? перспективных танков и боевых машин пехоты ????
Давайте зададим себе вопрос и попробуем ответить....
Может быть, тогда будет не до шуток ????

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

Есть выбор (и Проектировщик их отобразил в своей архитектуре)....но есть и требования МО РФ по ПО...не мы их придумали...и требования из года в год - жесткие.....

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

Проектировщик
Я ухожу с ветки форума...
Мне и моим ребятам все понятно....
Мой почтовый ящик у Вас есть....
Начинаем работать....спасибо.
С уважением, ИнженерЯ

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

АндрейЛ...
Это Ваше предположение....т.к. Проектировщик служил в 16 ЦННИС, он реально знает какие требования необходимо задавать к программному обеспечению.....
В виду того, что именно 16 формировал эти самые требования...и Проектировщик принимал непосредственное участие в этом....
Вы уж извините....
С уважением, ИнженерЯ

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

to Андрей Л.

Уважаемый Андрей Л!

По поводу применения СУБД MySQL-это конечно не для обсуждения. Давайте остановимся на Oracle и ее клонах! Только мы в своих разработках используем движки СУБД с объемом библиотек не более 1,2 М - главное требование наличие исходных кодов. Да соответственно они должны быть ориентированы под работу с приложениями в реальном масштабе времени. Посмотрите известную отечественную СУБД для реального масштаба времени Воронежского РЕЛЭКС, рекомендуемую для установки на контроллерах в системах реального времени с объемом 200 M - чувствуете разницу?
Теперь, что касается ID-сенсоров (датчиков), объектов базы данных, ID-сенсоров (датчиков), оптимизации объемов сообщений при организации обмена данными. ID - вводится специально, а не ради прихоти. Нам в базе данных нужно описать объекты со свойствами в противном случае зачем городить огород.

Ваш тезис: Знаете зачем в СУБД появился Variant и зачем начали думать над неудобным промежуточным форматом передачи параметров массивами, затем таблицами – потому что они пытаются сделать передачу максимально унифицированной, даже в ущерб производительности и приблизить модель к объектной передаче.                 

Существующие открытые международные  стандарты поддержки динамических моделей, как раз на это и ориентированы. Кроме того они базируются на поддержке онтологий предметной области. При организации обмена информацией между узлами используются онтологии. Это позволяет обеспечить передачу только относительно объектов и их свойств, которые изменились. Механизм работает по аналогии обмена, который когда-то был реализован в АСУВ "Маневр" - только теперь используется открытая международная объектно-ориентированная модель данных с базовым ядром сущностей, которое по желанию разработчика наращивается. Кроме того применяется технология Puch, которая обеспечивает проталкивание сообщений по низко-скоростным каналам связи в реальном масштабе времени. Онтологию предметной области нужно вести точно-также, как и КНСИ, любая система требует согласованного ИЛО. Однако при объектном подходе представления модели АСУ все делается гораздо проще и менее затратно.
          
Цитата
Вы хотите, чтобы ИнженерЯ подумал над API к этим устройствам в соответствие с теми требованиями, которые Вы закладываете в свою АСУВ?

Здесь Вы абсолютно правы! Заказчик, как правило задает оперативные требования. Есть ОКР в которых старый ДРИИТ МО прописал номера конкретных спецификаций. Что касается, чего бы Мы хотели от разработчиков составных частей АСУВ? Только одного, чтобы они использовали открытую международную модель данных и технологию ее поддержки, а что касается классов ее расширения и передачи документированных программных интерфейсов другим разработчикам - на мой взгляд пусть об этом думает заказчик и его НИУ МО. Разработчику нужно зарабатывать деньги, в том числе путем передачи SDK.

С уважением проектировщик  

Проектировщик - направьте меня по Линтер. Я ознакомился бегло с документацией и пока увидел ряд отличий от ORACLE
1. меньше типов данных чем ORACLE, в частности нет работы с объектными типами
2. очень большое внимание уделено работе с геометрическими параметрами, явно больше чем в ORACLE, особенно по визуализации
3. Упрощенная модель оптимизации и вывода системы из взаимных блокировок
4. Идентичные системы безопасности, во всяком случае я не увидел инструментов, которые позволили бы говорить о том, что Линтер является лидером в области обеспечения безопасности данных в системе.

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

Что-же в этой СУБД такого, что она лучше ORACLE (про клонов я не буду говорить)? При этом я понимаю, что ORACLE не подходит в качестве СУБД реального времени в условиях ограниченных массо-габаритных параметров и параметров охлаждения.

Подскажите - чего же я не вижу?

Проектировщик
что касается классов ее расширения и передачи документированных программных интерфейсов другим разработчикам - на мой взгляд пусть об этом думает заказчик и его НИУ МО. Разработчику нужно зарабатывать деньги, в том числе путем передачи SDK.

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

Разве это удобно? Вариант создания API АСУВ и открытия его для всех участников ГОЗ не принимается именно из-за коммерческой непривлекательности для разработчика?

to Андрей Л

Уважаемый собеседник!
Все, что остается мне сказать относительно СУБД  Линтер... - эта СУБД для систем реального времени не годится! Если внимательно посмотреть п. 73 у меня даже намека на ее применение нет. Но у меня четко сказано, что для решения своих задач мы используем движки СУБД - под задачи реального времени свой отдельный движок - сетевой СУБД. Есть свой движок полностью совместимый с PostgreSQL - добавьте к нему на Ваш вкус такие технологии как Hibernate или встроенную объектную СУБД. Вот в таких условиях мы и работаем. Хотя для этих целей есть такие классные зарубежные продукты, но НЕЗЗЯ...

На этом предлагаю тему закрыть!  Не пойму куда пропал с ветки  С4I?
Хотел предложить ему развить тему по ветке "Провала отечественного АСУВ-строения. IV часть" в части помочь проткнуть пузырь с хваленными отечественными IT - компаниями.
А он в это время, как пить дать ищет материал в НПО "Агат" или Китае по описанию Маневровых СЧГА и УСК. Еще про ПНФК - забыл - если найдете прошу поделиться!

to Андрей Л.

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

to Андрей Л

   Все дополнения и изменения к международным стандартам, относительно, реализованных технологий отечественными разработчиками должны вестись объединенной структурой   Заказчика и Минпромторга. Предметом ведения должны являться модель всей АСУ, КНСИ и онтологии предметной области.

to Андрей Л.

Цитата: "На гражданке, из того, что я прочитал в ветке - всё уже пройденный путь, п.72".

А кто собственно с Вами спорит? Изобретать ничего не надо! Все уже изобретено до нас! Поэтому я удивляюсь когда говорят  
давайте технологии из оборонки - будем переносить в гражданский сектор экономики. К информационным технологиям - это не относится! На мой взгляд незамедлительно нужно коммерческие разработки внедрять в оборонке. К сожалению уровень разработчиков ИТ-технологий в оборонке сильно отстает от специалистов гражданского сектора экономики. Но основная проблема в оборонке - заключается в том, что если туда сейчас придут отличные специалисты ИТ - отрасли ситуация не изменится. За последние 20 лет в оборонке разрушены школы специалистов-системщиков, т.к. на смену им пришли менеджеры новой России и военные-управленцы. Прошу не путать со специалистами пришедшими из НИУ МО. В организациях  АСУВ-строения не только не знают как делать, но и что делать. На мой взгляд спасение АСУВ-строения могут обеспечить только инициативные, мобильные, легко-управляемые компании, которые путем отсева выявят у себя самородков-системщиков. А уж они своим умом в кратчайшее время предложат для оборонки прорывные технологии и системотехнические решения.

Уважаемый Проектировщик

А кто собственно с Вами спорит? Изобретать ничего не надо! Все уже изобретено до нас! Поэтому я удивляюсь когда говорят

давайте технологии из оборонки - будем переносить в гражданский сектор экономики.

Т.е. Вы считаете, что самый оптимальный путь решения вопроса работы с грязными данными в СУБД уже найден?
Или может быть найден самый удачный путь работы с блокировками в СУБД? Или может быть использование контекста в СУБД является самым оптимальным механизмом динамической авторизации?

Вы уж простите - но я, как ИТ специалист, с Вами тут в корне не согласен. И хотел промолчать, поскольку Вы тему предложили закрыть, но замечу, что какой бы движок СУБД Вы не взяли - Вы столкнетесь с этими проблемами, точнее сталкиваетесь, и даже больше - клоны ORACLE содержат на уровне ядра ограничения в решении ряда проблем - т.е. Вы либо их принесли в АСУВ, либо решаете сами, дорабатывая движок СУБД.
И никогда Hibernate (тем более на яве) не заменит по производительности отработку объектов на уровне ядра.
Возникает вопрос - зачем дорабатывать то, что содержит искусственные ограничения (а в частности в MySQL ряд проблем могли быть ORACLE решены)?
Почему не выбирается вариант самостоятельной разработки движка, который снимет ряд проблем на уровне ядра системы, хотя бы со стороны минимизации нагрузки при решении задач. Ясно, что чем-то придется жертвовать, но зато ограничения будут осознанными и управляемыми.

К информационным технологиям - это не относится!

Т.е. Интернет Вы считаете ошибкой или исключением из правил?

К сожалению уровень разработчиков ИТ-технологий в оборонке сильно отстает от специалистов гражданского сектора экономики.

Причина этого, на мой взгляд, одна и она прозвучала в Ваших словах, цитирую:

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

Это называется пророков не видит оборонка в отечестве своем. Удивительно то, что русские программисты востребованы во всем мире! Кроме России.
И ещё более удивительно, что практически нигде программист не может получить такого колоссального опыта искусства программирования, кроме, как в оборонке (из-за сложности и масштабности задач) или при разработке биллинговых систем. Оборонка в сфере ИТ до сих пор является кузницей кадров - я это вижу своими глазами, правда не в задачах АСУВ (просто занимаюсь другими темами).

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

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

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