[image]

Архитектура борта

Теги:авиация
 
1 2 3 4 5 6 7 10
RU Alesandro #18.11.2003 16:45
+
-
edit
 

Alesandro
Серокой

координатор
★★★★
Трудоёмкость написания на ассемблере очень большая. Я под БРЭО не писал, зато другой эмбеддед софт писал. Бывало, просто не ту метку поставишь - и непонятно, почему не работает. просто отладка таких конструкций, как if, for на ассемблере очень много времени занимает. Особенно если сложный if. А например, 16-разрядная арифметика под 8-разрядный контроллер? А умножение? Так что когда Си появился на микроконтроллерах, я с радость на него перелез. Думаю, ситуация ПО для БРЭО мало отличается...
Ассемблерные вставки нужно делать там, где нужно быстродействиие.
   
+
-
edit
 

Nikita

аксакал

>ИМХО, никак не связано... Другое дело, что на "механике с автоматикой" (как на МиГ-29) эти вещи реализуются сложнее. :)

Ну так это связь и есть. Если сделать можно, но на это надо 10 лет времени, вместо года на цифре, то сами понимаете...

>В свое время пилоты на Кубинке некоторое время "привыкали" к СДУ

Гы... А уж сколько пилоты к F-16 привыкали, особенно к исходной машине, у которой ручка вообще не двигалась Таки пришлось небольшой ход добавить, для "стариков"...

>Ну, насчет "меркнут" - я полагаю, что это зависит от конкретного случая.

Ну вот до некоторого времени этот "случай" и был. А как только встали задачи посложнее 2+2 так ассемблер и умер.

>Кстати, просветите дилетанта: в чем там трудоемкость написания? Разве нельзя сделать какие-то "эмуляторы", чтобы минимизировать сложность процесса?

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

Aaz

модератор
★★☆
Valeri_, 18.11.2003 16:43:02:
Фиксирование направления полета при отпущенной ручке. Это не автопилот - отпустили ее при тангаже в N градусов, значит так и поедем. Соответственно, не нужно "откренивать" ручкой после бочки - желание сушки крутиться еще чуть не на 90 градусей вызывало у летавших на ней амов недоумение.

"Нет ничего практичнее хорошей теории!" (Ц) не помню чей.

Другой вопрос, а где не было проблем с СДУ?

О блин. Ну тогда я вообще не знаю, о чем говорить...

Хе, да как они еще могут работать с тем же АМРААМ - для них никто спецверсии делать не собирается

Что Вы, уважаемый - Вы представляете себе потребную пропускную способность?

...а я за монитором делом занимаюсь - все удовольствие стоит копейки.

Повторяю то, что уже было неоднократно сказано - Грипен сделал свой первый полет в 88 году...
 

??? А Вы полагаете, что "остановка вращения" чем-то технически отличается от режима "приведение к горизонту" в автопилоте? Почему не сделали - другой вопрос, я полагаю, что именно потому, что хотели сохранить "преемственность в характере управления" и не усложнять пилотам переучивание...
Интересно, у каких амов это "вызывало удивление" - у летавших на F-15?

Не только "чей", но, извините, и "как"... В оригинале там было "философии", а не "теории".

Ну, чтобы по этой причине потеряли первую (или вторую?) опытную машину - это все же не каждый день встречается...

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

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

Тогда что Вы мне об отстойности 1553 все время твердите, если эта задача, если я Вас правильно понял, до сих пор "решения не имеет", и все картинки надо пускать через РК?

Ну, так и занимайтесь, и гордитесь тем, что Вы умнее все конструкторов самолетов и БРЭО вместе взятых. Устал я, ей-богу, от Ваших постоянных экскурсов в "бытовуху"...

Повторяю то, что уже было неоднократно сказано (с - Ваш): ну, и какие же преимущества он имеет перед Су-32 (борт которого - еще для ИБ - начали вязать в начале-середине 80-х годов, т.е. по срокам эти машины сопоставимы)?
Ф-22 Ваши воззрения не подтверждает, и он для Вас архаика, "Грипен" - тоже... На "Глобал Хоуке" такие "шкафы", оказывается, наворочены - я сам удивился... Но все равно, согласно Вашим воззрениям, у нас "отстой", а вот на Западе - все прогрессивно.
Может, на "Рафале" или "Еврофайтере" все лучше обстоит? Но и там, оказывается, "законы природы" нарушать сложно: прогрессивные СУВ этих машин прогрессивные западники все еще не научили работать в режиме "воздух-поверхность" (то есть не только наши с этим по пять-десять лет возятся...).
   

Aaz

модератор
★★☆
Nikita, 18.11.2003 16:54:25:
Гы... А уж сколько пилоты к F-16 привыкали, особенно к исходной машине, у которой ручка вообще не двигалась Таки пришлось небольшой ход добавить, для "стариков"...

Ну вот до некоторого времени этот "случай" и был. А как только встали задачи посложнее 2+2 так ассемблер и умер.

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

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

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

Ниже - через абзац...

Я как раз имел ввиду, что все пишется на языке высокого уровня, а потом "автоматически транслируется" в ассемблер. Что этому мешает? Адекватных трансляторов создать так и не удалось (или это принципиально невозможно)?

Тут Вы, извините, сами себе несколько противоречите (абзац "перед предыдущим): оказывается, он все же не совсем умер? Именно это я и имел в виду...
   
+
-
edit
 

Nikita

аксакал

>Я как раз имел ввиду, что все пишется на языке высокого уровня, а потом "автоматически транслируется" в ассемблер.

Э-э-э... Вы же выступали за ваяние софта на ассемблере. Или я чего-то не понял ???

>Тут Вы, извините, сами себе несколько противоречите (абзац "перед предыдущим): оказывается, он все же не совсем умер? Именно это я и имел в виду...

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

Balancer

администратор
★★★★★
Alesandro, 18.11.2003 17:45:30:
Особенно если сложный if. А например, 16-разрядная арифметика под 8-разрядный контроллер? А умножение? Так что когда Си появился на микроконтроллерах, я с радость на него перелез. Думаю, ситуация ПО для БРЭО мало отличается...
Ассемблерные вставки нужно делать там, где нужно быстродействиие.
 

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

Aaz

модератор
★★☆
Nikita, 18.11.2003 18:47:27:
>Я как раз имел ввиду, что все пишется на языке высокого уровня, а потом "автоматически транслируется" в ассемблер.
Э-э-э... Вы же выступали за ваяние софта на ассемблере. Или я чего-то не понял ???

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

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

Ну, сравнивать с временами 20-30 лет назад, я полагаю, особого смысла не имеет - тогда память на борту была такой, что напрягались страшно, дабы в нее необходимый объем программ засунуть...
Офф: в период БЭСМ среди программеров (их тогда еще так и не называли - уважали профессию ) считалось высшим шиком умение читать и писать программы в машинных кодах...

Но если предположить то, во что я не верю - создание ИИ (скачок "сложности" ПО на несколько порядков), то потребность в объеме "под программы" и требования к быстродействию могут вырасти до размеров, несопоставимых с возможностями, и тогда может произойти "возрождение" ассемблера. Как Вы оцениваете такую версию - просто для иллюстрации? Или я опять все напутал?
   
GB Alesandro #18.11.2003 21:26
+
-
edit
 

Alesandro
Серокой

координатор
★★★★
Всё так, программа компилится и грузится так или иначе в хекс - кодах. Да. но в случает компилятора ЯВУ получается код менее оптимальный, более раздутый и как следствие менее быстродействующий и требующий больше ресурсов. Зато - удобство! Именно поэтому и пишутся ассемблерные вставки.
А читать в машинных кодах... Хм... Полезно теперь разве что отладчикам процессоров - тех, кто ядра пишут. По-моему, этот "шик" - просто рудимент вроде "нашла чем гордиться!"
А что касается создания нового ИИ - так "железо" тоже шустро поспевает. И тоже усложняется - под растущие задачи.
Опять же возращаясь к хекс-кодам - кто-то на Базе рассказывал, что ПЗУ для Бурана вообще лаборантки пинцетами набирали! Но за "шик" я это тоже принять никак не могу...
   

Aaz

модератор
★★☆
Alesandro, 18.11.2003 21:26:14:
Всё так, программа компилится и грузится так или иначе в хекс - кодах. Да. но в случает компилятора ЯВУ получается код менее оптимальный, более раздутый и как следствие менее быстродействующий и требующий больше ресурсов. Зато - удобство! Именно поэтому и пишутся ассемблерные вставки.

А что касается создания нового ИИ - так "железо" тоже шустро поспевает. И тоже усложняется - под растущие задачи.

Опять же возращаясь к хекс-кодам - кто-то на Базе рассказывал, что ПЗУ для Бурана вообще лаборантки пинцетами набирали! Но за "шик" я это тоже принять никак не могу...
 

Так и обясните, почему нельзя программу, написанную на ЯВУ, после отработки автоматически "транслировать" в коды "на земле", а потом "на борт" грузить уже без "трансляторов"? Потребовалась доработка - скорректировали программу на ЯВУ и заново "транслировали"... В чем проблема?

Я предположил "прорыв" в создании ПО, за которым "эволюционно-развивающийся" хард просто не успеет... Или Вы считает такое невероятным?

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

muxel

Энтузиаст реактивного движения
★☆
> Так и обясните, почему нельзя программу, написанную на ЯВУ, после отработки автоматически "транслировать" в коды "на земле", а потом "на борт" грузить уже без "трансляторов"? Потребовалась доработка - скорректировали программу на ЯВУ и заново "транслировали"... В чем проблема?

Ну так оно и делается вообще то. Только дело в том что автоматическая трансляция из ЯВУ в машинный код в критическом случае хуже ручной...
   
GB Alesandro #18.11.2003 21:44
+
-
edit
 

Alesandro
Серокой

координатор
★★★★
>Aaz>Так и обясните, почему нельзя программу, написанную на ЯВУ, после отработки автоматически "транслировать" в коды "на земле", а потом "на борт" грузить уже без "трансляторов"?

А разве это не так делается? На БРЭО работают бинарники программ. Разве кто-то сказал, что программа транслируется в процессе выполнения?

>Aaz>Я предположил "прорыв" в создании ПО, за которым "эволюционно-развивающийся" хард просто не успеет... Или Вы считает такое невероятным?

Да нет, все мы к примеру это пережили - это были 3D ускорители. Но всё же, к сожалению, железо делают под ПО, а не ПО под железо, поэтому исключать то же для БРЭО я не могу...
>Aаz>Просто когда требуется сделать 5-10 блоков, не дороже (а то и дешевле)...

Да. Но потом понадобятся ещё 5-10 блоков Других. И ещё... И ещё... Так что проще один раз сделать нормальную среду разработки - компилятор, чем каждый раз мучительно выискивать, где же я в коде вместо 0xd3 посавил 0xd7 ...
   

Aaz

модератор
★★☆
Alesandro, 18.11.2003 21:44:59:
На БРЭО работают бинарники программ. Разве кто-то сказал, что программа транслируется в процессе выполнения?

Но всё же, к сожалению, железо делают под ПО, а не ПО под железо, поэтому исключать то же для БРЭО я не могу...

Да. Но потом понадобятся ещё 5-10 блоков Других. И ещё... И ещё... Так что проще один раз сделать нормальную среду разработки - компилятор, чем каждый раз мучительно выискивать, где же я в коде вместо 0xd3 посавил 0xd7 ...
 

Тогда в чем прикол с применением ЯВУ?

То есть версия "не является полностью нереальной"? И что тогда, по-Вашему, может измениться в практике применения "бортового" ПО?

??? Я не вполне понимаю, при чем тут компилятор и лаборантки с пинцетами? Это как-то связано?
   

Aaz

модератор
★★☆
muxel, 18.11.2003 21:43:38:
> Так и обясните, почему нельзя программу, написанную на ЯВУ, после отработки автоматически "транслировать" в коды "на земле", а потом "на борт" грузить уже без "трансляторов"? Потребовалась доработка - скорректировали программу на ЯВУ и заново "транслировали"... В чем проблема?

Ну так оно и делается вообще то. Только дело в том что автоматическая трансляция из ЯВУ в машинный код в критическом случае хуже ручной...
 

"Нич-ч-ч-его не понимаю!!!" (м/ф "Следствие ведут Колобки").

Если все делается так, как я себе представлял, то в чем такой уж невиданный прогресс БРЭО, связанный именно с применением ЯВУ? Формально получается, что просто вводится "дополнительная операция": раньше писали сразу "в кодах", а теперь пишут на ЯВУ, а потом все это переводят в коды... Выигрыш, насколько я понимаю, получается только на стадии отработки программ, когда их можно "гонять" на наземных компах в составе моделирующих систем, тренажеров, имитаторов и проч. Так все выходит?
   

Aaz

модератор
★★☆
Alesandro, 18.11.2003 21:26:14:
А читать в машинных кодах... Хм... Полезно теперь разве что отладчикам процессоров - тех, кто ядра пишут. По-моему, этот "шик" - просто рудимент вроде "нашла чем гордиться!"
 

Ваши же (и не только Ваши) слова Вас и опровергают: если я правильно понимаю, до сих пор задача обнаружения ошибок в программах, "изложенных" непосредственно в кодах, остается актуальной. То есть если человек может найти ошибку в "конечном продукте", то ему не надо лезть в "исходник". Что изменилось? Разве что народ стал более ленив...
   
+
-
edit
 

avmich

координатор

Может, Балансер, Форт не выжил всё остальное по той же причине, по какой Фортран до сих пор царит в научных вычислениях?

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

muxel

Энтузиаст реактивного движения
★☆
> Если все делается так, как я себе представлял, то в чем такой уж невиданный прогресс БРЭО, связанный именно с применением ЯВУ? [...] Выигрыш, насколько я понимаю, получается только на стадии отработки программ, когда их можно "гонять" на наземных компах в составе моделирующих систем, тренажеров, имитаторов и проч

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

Как программили БРЭО в 80-е я не знаю, но тогда уже использовали всякие эмуляторы на базе ЕС ЭВМ и пр. и всякие макроассемблеры. За подробностями надо в "Компутерный музей" заглянуть

PS Извините, а из-за чего собственно спор то?
   

Aaz

модератор
★★☆
muxel, 18.11.2003 23:35:28:
Выигрыш в том, что применение ЯВУ позволяет разрабатывать и отлаживать в приемлемое время и с приемлемыми трудозатратами математическое обеспечения для современного БРЭО.

...и всякие макроассемблеры.

PS Извините, а из-за чего собственно спор то?
 

Все ясно - я таки преимущества понимал достаточно правильно...

О!!! А это слово я еще из тех времен помню!

Спор был о том, что западное БРЭО "прогрессивнее" нашего, а именно - по архитектуре. В качестве "одного из" признаков его "прогрессивности" мне и было приведено ПО на ЯВУ.
Правда, долгая возня с СУВ последних европейских истребителей как-то не демонстрирует столь уж разительного выигрыша по времени по сравнению даже с нашими допотопными системами. Но можно с уверенностью сказать, что без ЯВУ они ковырялись бы еще дольше... (правда, непонятно, на сколько, ибо процесс "ковыряния", насколько я знаю, все еще не закончен... ).
   
RU Alesandro #19.11.2003 00:37
+
-
edit
 

Alesandro
Серокой

координатор
★★★★
Насчёт преимущества нашего либо "ихнего" БРЭО не скажу, хотя, естественно, болею за наше. Я только говорил, что использование ЯВУ прогрессивней.
А лаборантки с пинцетами тут при том, что ввиду откровенной слабости средств разработки приходилось писать на ассемблере, в кодах и т.д. Но при этом считать, что это "круто" - ну всё равно что гордиться, что из принципа сидишь на ЕС-1841. То есть не из хобби - ибо при этом есть и нормальный комп, а вот просто не хочешь новый...
Ну да ладно, спор и правда уже непонятно о чём...
   

muxel

Энтузиаст реактивного движения
★☆
Насчет разработки мат.обеспечения для всяких бортовых ЦВМ:

"...Усложнение программируемых задач и рост их числа приводит к резкому повышению затрат на программирование и увеличению времени на создание программ. Для сокращения затрат и уменьшения времени на создание программ в 60-70-е годы интенсивно развиваются языки программирования высокого уровня (ЯВУ). Эти языки, по сравнению с машинными языками, в 3–6 раз уменьшают затраты труда на программирование. Однако для получения программ, на которых работает компьютер, т. е. программ на машинном языке, используются программы – трансляторы, преобразующие программы на ЯВУ в программы на машинном языке (МЯ).

Программы на МЯ, полученные после трансляции, обычно в 3–6 раз длиннее программ, написанных на МЯ. Таким образом, оттранслированная программа решения задачи требует для своего выполнения на том же компьютере в 3–6 раз большего времени, чем написанная на МЯ, и увеличенного в 3–6 раз объема памяти команд.

Для спецкомпьютеров трех поколений использование ЯВУ для программирования задач и управление процессом счета (ОС) являлось очень дорогой платой за сокращение сроков создания системы. Поэтому ЯВУ не получили широкого применения в системах со спецкомпьютерами первого, второго и третьего поколений.

Активное использование ЯВУ началось в спецкомпьютерах четвертого поколения, построенных на микропроцессорах, в которых вопросы экономии памяти и быстродействия перестали быть определяющими при формировании габаритно-весовых показателей компьютера."
// http://compmus9.valuehost.ru/histussr/special.htm

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

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

Первоначально кросс-системы создавались специально для разработки программ каждого типа управляющей ЭВМ. Постепенно эти системы совершенствовались и развивался сервис для разработчиков, так что к началу 70-х годов машино-ориентированные трансляторы и интерпретаторы в кросс-системах на универсальных ЭВМ стали занимать относительно небольшую часть. Остальное составляли средства визуализации для пользователей, документирования, формирования тестов и отладочных заданий, статического анализа корректности структуры программ и т. д., которые почти не зависили от особенностей управляющих машин. Поэтому выявилась необходимость создания адаптируемых трансляторов и интерпретаторов, настраиваемых на основе формализованных описаний архитектуры и системы команд управляющих ЭВМ. Эти описания автоматизированно транслировались в машино-ориентированные блоки трансляторов и интерпретаторов, что позволило на порядок сократить затраты на разработку кросс-систем для управляющих ЭВМ. На этих принципах в середине 70-х годов была разработана комплексная, многофункциональная инструментальная система ЯУЗА-6 на БЭСМ-6, которая была настроена на два десятка типов военных, управляющих ЭВМ, а затем кросс-система РУЗА на ЕС ЭВМ.

К концу 70-х годов разработкой программ для систем военного назначения в нашей стране занималось около ста тысяч специалистов, которые создавали одновременно сотни сложных комплексов программ. К этому времени их производительность труда повысилась на порядок - до 1-3 команд в день на человека. Особенно острой стала проблема борьбы с программными ошибками и обеспечения высокой надежности функционирования комплексов программ в реальном времени. Высокая стоимость и риск аварий при использовании реальных объектов для комплексной отладки программ заставил активно создавать стенды для имитации внешней среды в реальном времени на технологических ЭВМ.

Кросс-системы решали часть задач - первичную разработку и автономную отладку относительно небольших программ. Комплексная отладка в реальном времени крупных программ на технологических ЭВМ была невозможна, так как интерпретаторы замедляли исполнение программ в сотни раз. Поэтому начали применяться гибридные системы, в которых исполнение программ военных систем происходило на реальных управляющих ЭВМ во взаимодействии по каналам связи с технологическими ЭВМ, использовавшимися для имитации внешней среды и генерации тестов."
// http://compmus9.valuehost.ru/histussr/16.htm
   
Это сообщение редактировалось 19.11.2003 в 19:58

Aaz

модератор
★★☆
muxel, 19.11.2003 07:49:48:
Насчет разработки мат.обеспечения для всяких бортовых ЦВМ:
 

Благодарствую! А то самому искать такие вещи откровенно времени не хватает...
   
+
-
edit
 

Balancer

администратор
★★★★★
Aaz, 19.11.2003 14:50:10:
Благодарствую! А то самому искать такие вещи откровенно времени не хватает...
 

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

Aaz

модератор
★★☆
Balancer, 19.11.2003 19:55:19:
Можно б было и у меня в реале порасспросить Благо, я как раз прошёл все стадии программирования, от чтения голых HEX-кодов (и написания программ вручную в HEX-кодах) до скриптовых, функциональных и т.п. языков. И даже "борта" программил (хотя и "наземные" )
 

При всем моем к Вам уважении, вряд ли Вы можете что-то помнить, скажем, о такой штуке, как "многофункциональная инструментальная система ЯУЗА-6 на БЭСМ-6"... А в контексте этой дискуссии исторический аспект мне кажется важным.
   
+
-
edit
 

Valeri_

опытный

>Почему не сделали - другой вопрос, я полагаю, что именно потому, что хотели сохранить "преемственность в характере управления"

Кхе.. кхм. Если пилот не рулит - ему не нужно следить за самолетом. Это ОЧЕНЬ круто, это такая вещь, к которой очень легко привыкнуть и очень трудно отвыкнуть. Так что преемственность здесь не при чем - просто не смогли, или даже не подумали, что такое возможно.

>Не только "чей", но, извините, и "как"... В оригинале там было "философии", а не "теории". :)

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

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

Просто он еще не существует, и я про него мало чего знаю. Впрочем, могу сказать определенно - то, что рассматривали как Су-27УБ в начале 80-х, к тому, что есть сейчас, имеет косвенное отношение. Если есть, можете кинуть инфу по борту - общая структура, обработка РЛИ итп, с интересом обсудим. Глядя на Багеты разработки конца 90-х, априори думается, что не фонтан.

>Тогда что Вы мне об отстойности 1553 все время твердите, если эта задача, если я Вас правильно понял, до сих пор "решения не имеет", и все картинки надо пускать через РК?

Я же сказал - интерфейс для подключения мониторов по цифре достаточно давно существует. Легко догадаться, что называется он DVI. Но это - именно выход на отображение. А вот для обработки нам нужно иметь скоростные цифровые интерфейсы общего назначения - либо, как мудакам, управление по одному типу, картинки по другому. Так вот Вам критерий - современный перспективный борт использует один тип интерфейса и для того, и для другого.

>Я предположил "прорыв" в создании ПО, за которым "эволюционно-развивающийся" хард просто не успеет... Или Вы считает такое невероятным?

Есть такая штука - закон Мура. Несмотря на чистую эмпиричность, он выполняется уже много времени с завидным постоянством. Так что Ваше предположение именно невероятно.
   

YYKK

опытный

Есть такая штука - закон Мура. Несмотря на чистую эмпиричность, он выполняется уже много времени с завидным постоянством. Так что Ваше предположение именно невероятно.
 

Заглох он что то на процессорах.
   

Aaz

модератор
★★☆
Valeri_, 19.11.2003 20:26:23:
...просто не смогли, или даже не подумали, что такое возможно.

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

Просто он еще не существует, и я про него мало чего знаю.

Впрочем, могу сказать определенно - то, что рассматривали как Су-27УБ в начале 80-х, к тому, что есть сейчас, имеет косвенное отношение.

Если есть, можете кинуть инфу по борту - общая структура, обработка РЛИ итп, с интересом обсудим.

Глядя на Багеты разработки конца 90-х, априори думается, что не фонтан.

Так вот Вам критерий - современный перспективный борт использует один тип интерфейса и для того, и для другого.
 

Давайте я попробую порассуждать, исходя из Вашей логики, а Вы меня, если что, поправите. Итак:
Изначально F-16 не мог применять УРСД, в то время, как Су-27 и МиГ-29 это делать могли "от рождения". Следовательно, БРЭО "Фалкона" - полный отстой по сравнению с отечественным, ибо оно не могло обеспечивать режимы, доступные нашим СУВ. Американцы "просто не смогли". (с - Ваш)
Похоже?

Виноват, действительно резковато дернулся...
"Нет ничего практичнее, чем хорошая философия." (В.А.Канке - хотя изначально, кажется, все же не его...).
Согласимся на ничью?

Насчет "не существует" я уже говорил - машина готова к серии, а что не производится, так это к "прогрессивности" БРЭО отношения не имеет.
"Самые общие" данные по архитектуре (а мы говорим в основном о ней) здесь давали: всё (в моей трактовке - подавляющее большинство ) оборудование завязано на ОДИН (триплированный?) канал инф. обмена по 1553. Это, по Вашему представлению, архаизм и отстой? Чем это хуже сети на "Грипене"?

Извините, но я говорил не УБ, а ИБ - или это у Вас просто опечатка?

Я попробую Фомина попросить - пусть поднимет свои старые связи в НИИАС. Но обещать что-то сложно, как Вы понимаете...

Я же Вас постоянно призываю глянуть на БРОЭ "Глобал Хоука", но Вы мои призывы столь же постоянно игнорируете. Эти "шкафы", по-Вашему - "фонтан"? И это они - конца 90-х / начала 2000-х, а "Багет", если я не путаю, все же несколько древнее.

Где этот "современный прспективный борт" (кстати, он таки современный, то есть существующий сейчас, или перспективный, то есть еще неизвестно, когда будет?, который это делает? Пример, плиз...
   
1 2 3 4 5 6 7 10

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru