F-35: пациент скорее жив?

t.b.> я правильно понимаю что под синхронизацией понимается работа разных подсистем в единой координатной и временной системе ?

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

m.0.> Весь борт в полете - да. Но несколько сомневаюсь, что не предусмотрена ручная принудиловка перезагрузки данных систем в полете (точнее включение встроенного контроля). При этом наверняка у БРЛС своя БЦВМ, возможно у оптики и DAS тоже.

Неточно выразился. Как я понял можно попробовать перегрузить БРЛС, DAS и т.д. по отдельности, но это иногда не помогает. Перегрузка всего вместе с центральной системой помогает 100%, но так можно только на земле.
Собственные процессоры есть у всего. У DAS вычислительные мощности побольше чем у БРЛС просто из за гораздо большего потока данных.

m.0.> При отказе скорее всего может выполняться контроль крайней записи СОК насчет наличия отказов этих систем и снова включение рабочих режимов, а это достаточно быстро.

Отказа как такового нет. "рассыпается" общая информация сведенная со всех датчиков.

m.0.> Куда уж больше то?

Обещают. Прогресс в матрицах есть и заметный.

tarasv> Да когда информация об обстановке полученная с разных датчиков сводится в единую обрабатывается и отображается совместно.


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

tarasv> Отказа как такового нет. "рассыпается" общая информация сведенная со всех датчиков.

Что в лоб, что по лбу.

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

 

tarasv>> Отказа как такового нет. "рассыпается" общая информация сведенная со всех датчиков.
V.Stepan> Что в лоб, что по лбу.

Какое это имеет отношение к тому что проблема в F-35 скорее всего не регистрируется СОК как отказ и метод перегрузить тот компонент где отказало скорее всего не работает?

t.b.> и можно предположить что потребная точность по времени и координатам такова что погрешности возникающие при заливе данных из бцвм слишком велики ...

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

tarasv> Если бы причина была в столь банальных ошибках округления и синхронизации часов то ее давно бы решили. А вот ошибку в вынужденно асинхронном коде на десятках процессоров живущих своей жизнью можно искать ой как долго. А засинхронизировать все и вся невозможно потому что потоки данных большие и синхронно их не обработать. Естественно что все это ИМХО и гадания.


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

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

m.0.>> Весь борт в полете - да. Но несколько сомневаюсь, что не предусмотрена ручная принудиловка перезагрузки данных систем в полете (точнее включение встроенного контроля). При этом наверняка у БРЛС своя БЦВМ, возможно у оптики и DAS тоже.
tarasv> Неточно выразился. Как я понял можно попробовать перегрузить БРЛС, DAS и т.д. по отдельности, но это иногда не помогает. Перегрузка всего вместе с центральной системой помогает 100%, но так можно только на земле.

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

tarasv> Собственные процессоры есть у всего. У DAS вычислительные мощности побольше чем у БРЛС просто из за гораздо большего потока данных.

Не думаю, у навороченных БРЛС (АФАР\ПФАР) как правило два отдельных функциональных вычислительных блока (даже ежели они конструктивно объединены в одной БЦВМ): управление работой (режимами) и обработка информации. DAS в принципе пока обеспечивает только грубое ЦУ, поэтому вычислительные мощности там должны быть более хилые чем у БЦВМ БРЛС (тем более у интегрированных).

m.0.>> При отказе скорее всего может выполняться контроль крайней записи СОК насчет наличия отказов этих систем и снова включение рабочих режимов, а это достаточно быстро.
tarasv> Отказа как такового нет. "рассыпается" общая информация сведенная со всех датчиков.

Ну значит в итоге рассыпается или глючит (с недопустимыми ошибками) сам алгоритм DFu (data fusion) и они пока просто не могут готовить исходную инфу для него и пытаются сразу выполнить его в реале (скорее всего валят всю в одну кучу по мере поступления без обработки\с большими ошибками и др. по синхроканалу). Впрочем, это ихние проблемы.

m.0.>> Куда уж больше то?
tarasv> Обещают. Прогресс в матрицах есть и заметный.

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

t.b.> так то в гражданских применения асинхронные потоки данных давно уже сотнями на объект используются и нечего дебажим ...

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

m.0.> Естественно, хотя сделать полную перезагрузку (ПО + исходные данные + оперативка) в полете пока никто в полном фарше не может и обосновано не решается это делать. Но рано или поздно сделают.
В именно таком виде - это с вероятностью икс будет приводить к новостям на первой полосе, а потом многолямным искам от родственников погибших.
А вот ежели вся эта интеграция будет в виртуалке ака файле, и периодически будет параллельно запускаться новый такой файл, а старый убиваться, то это станет неплохим костылём от подобных зависаний (в плане пофиг, что зависло, в течение икс секунд само отвиснет в связи с убийством зависшего файла)
Ну или первые признаки зависона чтоб давали триггер на запуск другого такого файла, а предыдущий убивался.. Это будет иметь более быструю реакцию, пмсм..
Хотя конечно, ресурсов потребует конски, но с этим прогресс идёт...

m.0.> DAS в принципе пока обеспечивает только грубое ЦУ,
а почему только грубое?
Это тот же оптический-ик-уф (сколько там диапазонов) канал.
Так что, ЦУ вполне нормальное. Распределение касается лишь того, что при переходе цели от одного датчика к другому, ЦУ и отслеживание не сбрасывается.

m.0.> (задержкой не более, примерно 0,5 с).
В воздушном бою полсекунды - это дохренища!
Задержка отображения на полсекунды при пилотировании по приборам будет означать полнейшую неспособность пилотировать самолет в actual IMC кроме как мягко держаться за ручку в крузе, когда самолет идет по эшелону и не подвергается внешним воздействиям.
Если эволюции противника видишь с задержкой в полсекунды - ты уже труп.
Неважно, насколько верткий твой самолет, ты труп.

ЭДСУ, к примеру, проверяют и корректируют положения плоскостей с частотой 30 герц.

m.0.>> ... хотя сделать полную перезагрузку (ПО + исходные данные + оперативка) в полете пока никто в полном фарше не может и обосновано не решается это делать...
Bredonosec> В ... таком виде - это с вероятностью икс будет приводить к новостям на первой полосе...
Bredonosec> А вот ежели вся эта интеграция будет в виртуалке ака файле, и периодически будет параллельно запускаться новый такой файл, а старый убиваться, то это станет неплохим костылём от подобных зависаний...

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

m.0.>>... (задержкой не более, примерно 0,5 с).
Bredonosec> В воздушном бою полсекунды - это дохренища!...

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

m.0.> Рад за Вас да только в данном случае перед началом вычислений должна быть выполнена привязка по времени не только поступившей инфы от различных внутренних датчиков, но и в внешних + сняты параметры некоторых бортовых средств в действующих режимах этих датчиков + извлечена инфа из памяти. И усе это должно быть замешано в одном алгоритме и решение выдано в реале (задержкой не более, примерно 0,5 с). Так что задача может быть гораздо сложнее, чем кажется на первый взгляд.


Это я прекрасно понимаю ... я какбы под гражданским применением понимал АСУТП а не более приземленные задачи ...

tarasv> Какое это имеет отношение к тому что проблема в F-35 скорее всего не регистрируется СОК как отказ

Самое простое. От того, что это не отказ по документам, он ничем от отказа де-факто не отличается.

m.0.> Не думаю, у навороченных БРЛС (АФАР\ПФАР) как правило два отдельных функциональных вычислительных блока (даже ежели они конструктивно объединены в одной БЦВМ): управление работой (режимами) и обработка информации.

У вычислителей F-35 централизовання архитектура, такая-же как у F-22. В самой APG-81 как и в APG-77 есть только контроллер антенны. Сигнал после преобразования на ПЧ передается в ICP - центральную вычислительную систему всего самолета и первичная обработка сигнала производится уже там.

m.0.> DAS в принципе пока обеспечивает только грубое ЦУ, поэтому вычислительные мощности там должны быть более хилые чем у БЦВМ БРЛС (тем более у интегрированных).

Поток первички с DAS однозначно больше чем с БРЛС. В DAS шесть 16MP каналов по 30 кадров/сек тоесть 2.8G/сек 12битных отсчетов. В БРЛС такая скорость оцифровки сигнала просто не нужна, полоса пропускания приемника намного меньше даже при работе шумоподобным зондирующим сигналом. Вторичная обработка у них уже общая потому что sensor fusion.

t.b.> так то в гражданских применения асинхронные потоки данных давно уже сотнями на объект используются и нечего дебажим ...

В гражданских системах обычно нет жесткого real-time. Поэтому процесся один раз из сотни например запрос на рекламу не за 15мс, а за 30мс рискуют только долями цента, а не потерей информации об обстановке в бою. А там где жесткий RT есть или алгоритмы достаточно простые (как например в пресловутом high-frequency trading) или потоки данных менее скоростные как у УВД.

tarasv>> Какое это имеет отношение к тому что проблема в F-35 скорее всего не регистрируется СОК как отказ
V.Stepan> Самое простое. От того, что это не отказ по документам, он ничем от отказа де-факто не отличается.

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

tarasv> Поток первички с DAS однозначно больше чем с БРЛС. В DAS шесть 16MP каналов по 30 кадров/сек тоесть 2.8G/сек 12битных отсчетов.
Откуда дровишки?! Вроде-ж там матрицы мегапиксельного класса были, 12801024.

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

Поздравляю с изобретением stateless программ и метода контрольных точек.

Bredonosec> Хотя конечно, ресурсов потребует конски, но с этим прогресс идёт...

Неа. Нихрена не конски. Так работала БЦВМ посадочного модуля Eagle. Это который на Луну. И это спасло первую посадку на Луну, когда из-за ошибки в технической документации загрузка процессора превысила 100% — при этом происходил автоматический рестарт с последней контрольной точки с перезапуском ПО, что позволяло хоть как-то контролировать ситуацию. И дало время на принятие правильного решения о пропуске проблемной стадии программы.

Некоторые разработчики вообще делают принудительный рестарт несколько раз в секунду, это бывает проще, чем искать "плавающий" отказ. Грубо и неэстетично, да, но проблему решает хоть как-нибудь.

tarasv> В гражданских системах обычно нет жесткого real-time. Поэтому процесся один раз из сотни например запрос на рекламу не за 15мс, а за 30мс рискуют только долями цента, а не потерей информации об обстановке в бою. А там где жесткий RT есть или алгоритмы достаточно простые (как например в пресловутом high-frequency trading) или потоки данных менее скоростные как у УВД.


вся пром автоматика в опастных отраслях - 25мс на реакцию и тройной запас ...

Scar> Откуда дровишки?! Вроде-ж там матрицы мегапиксельного класса были, 12801024.

И есть, во всяком случае до последнего времени. Но с микросканированием 4:1 ценой расхода кучи памяти и процессорного времени. Одна из причин разработки обновленой DAS - появление 4Kx4K матриц для которых это не нужно.

t.b.> вся пром автоматика в опастных отраслях - 25мс на реакцию и тройной запас ...

На каком производстве промавтоматика получает на вход разнородные потоки данных суммарно под 10Gb/sec которые надо обрабатывать нетривиальными алгоритмами например выделяя цели и угрозы?
Я с промавтоматикой не сталкивался. Из того что приходилось читать сложилось мнение что уровень сложности там как у FADEC который многопараметрический, умный но все-же PID регулятор остро заточенный под свою узкую облась - управлять ТРД.

tarasv> На каком производстве промавтоматика получает на вход разнородные потоки данных суммарно под 10Gb/sec которые надо обрабатывать нетривиальными алгоритмами например выделяя цели и угрозы?
tarasv> Я с промавтоматикой не сталкивался. Из того что приходилось читать сложилось мнение что уровень сложности там как у FADEC который многопараметрический, умный но все-же PID регулятор остро заточенный под свою узкую облась - управлять ТРД.

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

tarasv> На каком производстве промавтоматика получает на вход разнородные потоки данных суммарно под 10Gb/sec которые надо обрабатывать нетривиальными алгоритмами например выделяя цели и угрозы?

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



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

Это всего лишь одна очень-очень узкая область.