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