От bedal
К Flanker
Дата 23.11.2010 21:57:35
Рубрики Прочее; Современность; ВВС;

Ну вот про то, что я точно знаю, можно?

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

Конечно, робот может по-настоящему показать себя в аппарате, который изначально спроектирован под него. И при этом у робота есть грандиозное, по-настоящему ещё не использованное преимущество перед человеком: он, робот, оценивает ситуацию и управляет в темпе БЫСТРЕЕ процесса. А человек - медленнее, он реагирует уже на результаты, а не на развитие процесса.

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

>Как будет работать та же электроника если, к примеру, две трети тех же датчиков статдавления умрут или будут ложняки гнать?
Отвечу точно - нормально будет работать.

>А тренированный экипаж с этим справиться, "на руках" посадит, как тот же 148 недавно.
Мне кажется, ссылки на катастрофические ситуации - приём не вполне корректный. Давайте поговорим о куда более простых и куда более частых ситуациях.
Полно случаев, когда в относительно невинной ситуации экипаж всё гробит. На одну аварию, когда спасает - приходятся тысячи, когда гробит. И этих тысяч угробленных беспричинно - у робота не будет.

Как Заказчик - что бы Вы предпочли? Если убрать сугубо социальные причины "я боюсь довериться железке", конечно.
От Flanker
К bedal (23.11.2010 21:57:35)
Дата 24.11.2010 17:07:51

Re: Ну вот...

>Системы, вполне успешно фильтрующие треть и больше недостоверной (что хуже отказа) телеметрии - очень даже существуют и вполне распространены.
>Сама программа управления работает по оценённому информационному полю и вполне успешно справляется, даже если отрезать до половины потока телеметрии.
Читаем внимательно, я говорю про ДВЕ трети. Треть отрезать это как два пальца. Банальное осреднение всех показаний, сравнение всех со средним, выкидывание наиболее далекого и еще раз осреднение показаний оставшихся. Все.

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

>>Как будет работать та же электроника если, к примеру, две трети тех же датчиков статдавления умрут или будут ложняки гнать?
>Отвечу точно - нормально будет работать.
Отвечу точно, задолбался я после таких вот уверенных косяки на летных испытаниях вылавливать и исследования проводить, чего это эта куча компов себя так повела и что они там друг другу понавыдавали.
Если умрут - не беда, а вот если подвирать будут вот тут ваша система поведет себя по всякому. Или если один умер, а второй привирает.
А если учесть еще то, что собственно ПО, как правило, пишут люди далекие от понимания процесса того, что собственно происходит с самолетом в воздухе и обычно в рамках своей узкой специализации, то вероятность схода с ума системы из-за ошибки программиста далеко не нулевая. Почему и доводка ПО современных самолетов занимает столько времени и денег. Короче наелся я этого на своей работе по уши и на самолете-роботе без пилота в кабине не полечу. Там АЗС банально дернуть некому случись чего.
>>А тренированный экипаж с этим справиться, "на руках" посадит, как тот же 148 недавно.
>Мне кажется, ссылки на катастрофические ситуации - приём не вполне корректный. Давайте поговорим о куда более простых и куда более частых ситуациях.
>Полно случаев, когда в относительно невинной ситуации экипаж всё гробит. На одну аварию, когда спасает - приходятся тысячи, когда гробит. И этих тысяч угробленных беспричинно - у робота не будет.
Полно, согласен, никто не предлагает заменять автоматику человеком, но и заменять автоматикой человека мягко говоря преждевременно.
>Как Заказчик - что бы Вы предпочли? Если убрать сугубо социальные причины "я боюсь довериться железке", конечно.
И как заказчик и как разработчик - робота с человеком рядышком.
От bedal
К Flanker (24.11.2010 17:07:51)
Дата 25.11.2010 09:05:02

Re: Ну вот...

>Читаем внимательно, я говорю про ДВЕ трети.
и так бывает..

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

Но и это только один приём. В целом оценка состояния - одна из самых алгоритмически сложных задач в АСУ ТП (каковой управление самолётом и является, по сути).

>>Какие-то это гуманитарные рассуждения, в технике они обычно не работают, не правда ли?
>Не правда.
Ну, не сходимся по этому вопросу - ладно.

>>>Как будет работать та же электроника если, к примеру, две трети тех же датчиков статдавления умрут или будут ложняки гнать?
>>Отвечу точно - нормально будет работать.
>Отвечу точно, задолбался я после таких вот уверенных косяки на летных испытаниях вылавливать
Я уже писал - за военные решения я не подписывался. Есть области, в которых по совершенно непонятным мне причинам из года в год культивируются примитивные до изумления подходы. Например - программы управления автомобилями. Тупость там восхитительная.

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

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

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

>Почему и доводка ПО современных самолетов занимает столько времени и денег.
Потому, что спроектировано паршиво, на основании собственного узкого опыта, а не мирового опыта. Управление самолётом - не самая сложная из задач, откровенно говоря.

В целом, мне кажется, мы исчерпали тему? Я бы даже сказал - непотему :-)
Если интересно продолжить - давайте в личку?
От Flanker
К bedal (25.11.2010 09:05:02)
Дата 25.11.2010 12:03:53

Re: Ну вот...

>>Читаем внимательно, я говорю про ДВЕ трети.
>и так бывает..

>>Треть отрезать это как два пальца. Банальное осреднение всех показаний, сравнение всех со средним, выкидывание наиболее далекого и еще раз осреднение показаний оставшихся. Все.
>банальное осреднение - детский сад. Уверяю Вас - я действительно знаю, о чём пишу, программы Оценки и Восстановления Состояния мне знакомы.
Да я вижу. Только я вам как специалисту в своей области пытаюсь объяснить почему эти вещи будут очень консервативно и по частям внедрятся в авиации (в гражданской по крайней мере) и дублирующий элемент в виде пилотов еще долго будет присутствовать
>Потому в серьёзных задачах решается обратная задача в полном объёме, и даже более того. Прямая задача - по известному положению в пространстве, известным скоростям и т.п. посчитать значения параметров в конкретных точках. Обратная - по значениям в отдельных точках воспроизвести полное состояние модели. Работа задачи ОС (ОВС) - решить обратную задачу, потом прямую - и получить, в каких точках значения не могут быть такими в данном состоянии модели. Обратите внимание - то, что вы писали, по сути, то же самое, но состояние модели считается заранее (и очень грубо) известным.

>Но и это только один приём. В целом оценка состояния - одна из самых алгоритмически сложных задач в АСУ ТП (каковой управление самолётом и является, по сути).

>>Отвечу точно, задолбался я после таких вот уверенных косяки на летных испытаниях вылавливать
>Я уже писал - за военные решения я не подписывался. Есть области, в которых по совершенно непонятным мне причинам из года в год культивируются примитивные до изумления подходы. Например - программы управления автомобилями. Тупость там восхитительная.

>>и исследования проводить, чего это эта куча компов себя так повела и что они там друг другу понавыдавали.
>делали по заранее определённому ТЗ :-)
А по другому не бывает :)
>>Если умрут - не беда, а вот если подвирать будут вот тут ваша система поведет себя по всякому. Или если один умер, а второй привирает.
>Да, это самая серьёзная ситуация. А ещё есть дребезг, когда выдаётся куча значений вокруг истинного, но каждое конкретное - ложное. А ещё нереальная скорость изменения значения датчика, а ещё запаздывание, когда старые данные одних датчиков приходят позже, чем новые других, а ещё, а ещё...
>Вот потому-то и решать такую проблему надо не внутри общей программы управления, как это часто делают в недоразвитых по этой части областях, а в отдельной задаче Оценки и Восстановления Состояния Модели.
>То есть должна существовать модель в явном виде. И программы-клиенты (та же программа управления) используют параметры модели, а не значения датчиков. Такой подход даёт возможность сделать серьёзный скачок в качестве продукта.

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

>В целом, мне кажется, мы исчерпали тему? Я бы даже сказал - непотему :-)
В принципе да.
Вы только что сами написали, почему путь этих методов в авиацию будет еще долог и тернист и летчики еще долго сидеть там будут. Помимо чисто алгоритмической задачи, которая действительно не самая сложная, существует еще куча "оврагов", начиная от организационных и заканчивая чисто техническими и производственными. Как пример вы тарировать свои тыщи датчиков запаритесь :). Мы вон от трех своих взаимности добиться не могли долгое время, чтоб в допуске разбежка была.
От tarasv
К bedal (23.11.2010 21:57:35)
Дата 24.11.2010 08:22:51

Re: Ну вот...

>>Как будет работать та же электроника если, к примеру, две трети тех же датчиков статдавления умрут или будут ложняки гнать?
>Отвечу точно - нормально будет работать.

"Не всегда" (с) отказа 3х из 24х датчиков СВС B-2 три года назад оказалось достаточно чтобы он разложился на взлете.

Орфографический словарь читал - не помогает :)
От bedal
К tarasv (24.11.2010 08:22:51)
Дата 24.11.2010 11:27:56

Добавлю, так как Ваш пример очень хорош:

Ограниченность человека, неспособность обрабатывать большие потоки информации, приводят к очень малому числу датчиков. Отказ трёх из 24 - конечно, очень серьёзно и труднопреодолимо. Ну так, учитывая, что даже 2400 датчиков составят процент от общей стоимости, и на "правильном" БПЛА их должно быть много. Желательно - разных по физическим принципам.
От Flanker
К bedal (24.11.2010 11:27:56)
Дата 24.11.2010 20:38:08

Re: Добавлю, так...

>Ограниченность человека, неспособность обрабатывать большие потоки информации, приводят к очень малому числу датчиков. Отказ трёх из 24 - конечно, очень серьёзно и труднопреодолимо. Ну так, учитывая, что даже 2400 датчиков составят процент от общей стоимости, и на "правильном" БПЛА их должно быть много. Желательно - разных по физическим принципам.
Неужели вы думаете что пилотам инфу гонят ото всех 24 датчиков. Да нет батенька если все 24 датчика меряют одно и тоже (скоростной напор или расход топлива к примеру), то комп обрабатывает их показания и результат использует для своей работы и его же выдает пилотам на индикацию. Так что там походу комп начал гнать пургу, а летуны это вовремя не засекли.
От bedal
К Flanker (24.11.2010 20:38:08)
Дата 25.11.2010 08:26:52

Re: Добавлю, так...

>Неужели вы думаете что пилотам инфу гонят ото всех 24 датчиков.
Вот именно, что не думаю. И зачем тогда пилот? Оценивать ситуацию по ненаблюдаемому режиму? Добавлять к ошибкам компа ошибки человеческие?

>Да нет батенька если все 24 датчика меряют одно и тоже (скоростной напор или расход топлива к примеру), то комп обрабатывает их показания и результат использует для своей работы и его же выдает пилотам на индикацию. Так что там походу комп начал гнать пургу, а летуны это вовремя не засекли.
Если 24 датчика меряют одно и то же (и желательно на разных физ.принципах, например, Пито и термосопротивления - для скоростного напора) - то сделать программу, использующую ошибочные значения, можно только сдуру.
От Flanker
К bedal (25.11.2010 08:26:52)
Дата 25.11.2010 11:34:26

Re: Добавлю, так...

>>Неужели вы думаете что пилотам инфу гонят ото всех 24 датчиков.
>Вот именно, что не думаю. И зачем тогда пилот? Оценивать ситуацию по ненаблюдаемому режиму? Добавлять к ошибкам компа ошибки человеческие?
Пятой точкой почуствовать что, что то не так. Не у всех получается, но тем не менее.

>>Да нет батенька если все 24 датчика меряют одно и тоже (скоростной напор или расход топлива к примеру), то комп обрабатывает их показания и результат использует для своей работы и его же выдает пилотам на индикацию. Так что там походу комп начал гнать пургу, а летуны это вовремя не засекли.
>Если 24 датчика меряют одно и то же (и желательно на разных физ.принципах, например, Пито и термосопротивления - для скоростного напора) - то сделать программу, использующую ошибочные значения, можно только сдуру.
Это верно и тем не менее регулярно встречается. Про 24 датчика одного параметра на Б-2 кстати врядли. Это скорее всего общее количество датчиков в СВС.
От bedal
К tarasv (24.11.2010 08:22:51)
Дата 24.11.2010 11:08:05

ну. тут я не виноват :-) Я за В-2 и вообще военные системы не подписывался

а всякие гражданские системы SCADA без оценивания телеметрии - не катят.
Схема такая - есть телеметрия, она оценивается и _восстанавливается_, так что создаётся поле параметров режима. Программы-клиенты используют именно параметры, так что значения в точке берутся вне зависимости от достоверности конкретного измерения (и даже наличия датчика на этом месте вообще).

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

Добавлю - в ходу ещё задачи оценки надёжности (Contingency Analysis) N-1, N-2 и т.д. То есть имеем список критического оборудования (не телеметрии, а именно оборудования) и регулярно рассчитываем поведение при отказе этого оборудования. Одного из списка - это N-1, двух одновременно (N-2) и так далее в зависимости от наличия вычислительных мощностей. Задача прямая и гораздо проще "оценки состояния",но расчётов нужно много, очень много по объёму. Наличие таких решений даёт возможность очень быстрых управляющих воздействий при возникновении реальных неприятностей. То есть, в конце-концов, использует свободный вычислительный ресурс в "спокойной" обстановке для решения задач в обстановке критической.

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