Цитата: iz_kirova от 26.10.2019 00:03:10Отвечаю, вероятнее, раз этак в тысячу. Потому, что: обрыв, замыкание, забивание помехами одним из устройств, сидящих на шине, просадка сигнала пробитым портом одного из устройств... вариантов оборвать цифровую связь - десятки. И большая их часть - повреждения не самой шины, а "болтающих" контроллеров и их портов. Вы не осознаете сложности организации цифровой передачи данных, сколько на этой паре проводков висит микроэлектроники.
.
Хочу поблагодарить Вас за относительно конструктивное отношение к процессу дискуссии.
Далее, о сути Ваших претензий.
.
Как страшно жить...
Ну, а летать самолётами, имеющими электродистанционную систему управления (ЭДСУ, или, по-ихнему,
Fly-by-Wire (FBW) Primary Flight Controls), таки, вообще, будто в "русскую рулетку" играть. :)
.
На самом деле, Вы, как обычно, целиком и полностью, полагаетесь на свою дремучую "интуицию", не имея ни малейшего представления о том, каким образом,
физически, на "языке" OSI, передаются цифровые потоки по шине 629 (именно к ней, действительно, подключено несколько передающих устройств) в современной авионике - "...
сколько на этой паре проводков висит микроэлектроники..." (???)
. Ну и, тем более, ещё хуже у Вас с пониманием об использующихся на борту Боинга 777 способах обеспечения (и существенного повышения (!), по сравнению с эпохой "до") заданной отказоустойчивости FBW.
.
Во-первых, если говорить о шине 717, таки на "пару её проводков"
подвешено всего лишь ОДНО передающее устройство, DFDAU, и одно приёмное - FDR. Мало того, DFDAU ещё и зарезервировано, так как при отказе основного, находящегося в левом "кабинете" (cabinet) AIMS, к "двум проводкам" подключается "правое" DFDAU из соседнего "кабинета" .
.
Во-вторых, в отличии от Вас, я прекрасно "осознаю",
сколько на этой паре проводков висит "микроэлектроники". К четырёхкратно зарезервированной шине 629 (systems data bus) подсоединено 8 функциональных стройств (итого, имеется 8 портов), и, ровно столько же - к троекратно зарезервированной (flight controls data bus)..
.В-третьих, с теорией надёжности и современной практикой её применения, у Вас тоже напряг. Иначе бы, Вы не стали пулять своим сногсшибательным: "...вероятнее, раз этак в тысячу...". Поэтому, просвещаю Вас - супернадёжная отказоустойчивость (fault tolerance) ЭДСУ Боинга 777 обеспечивается, как на аппаратном, так и на программном уровнях. Долго перечислять все методы её обеспечения (Тибрус икотой изойдёт, увидев мои "простыни" ), но, если Вам интересно, могу изложить их, и в деталях. Пока же, только тисну гифку, демонстрирующую аппаратное резервирование (от двукратного до четырёхкратного, см. цифровое содержимое красных квадратиков) ключевых элементов вышеприведённой схемы...Цитата: iz_kirova от 26.10.2019 00:03:10Ровно также глубоко ошибочны ваши представления о фреймах.
.
Я был бы очень благодарен, если бы Вы предъявили мне конкретные мои якобы "ошибочные" суждения, и ссылки на надёжные источники, которые подтверждают Ваше мнение. Со своей стороны, могу предоставить скрины реальной документации производителя (Боинга), подтверждающие достоверность моих представлений по этому вопросу. Что есть у Вас, за обшлагом рукава?
Цитата: iz_kirova от 26.10.2019 00:03:10Потому, что под вас и ваши самолеты ни кто микрухи выпускать не станет - не та серийность.
.
Ошибаетесь.
Есть такие
партии микрухи! (С)
.
.
Что будем делать?
Вот с этим, Вашим:
Цитата: iz_kirova от 26.10.2019 00:03:10...В авиации используется серийная индустриальная база. В результате чего авиационные протоколы на физическом уровне базируются на отработанных промышленных решениях. Именно так достигается надежность - серийностью и отработанностью, а не эксклюзивом. Поэтому в части параметров записи прав ваш оппонент. Танцы идут от контроллера.
.
Отчего, танцевать теперь будем?
Цитата: iz_kirova от 26.10.2019 00:03:10...Зачем вычислять то, что требуется просто хранить? Вот ровно так же и у конструкторов. Есть правила организации хранения данных. Целая наука, как правильно и надежно хранить данные. Есть правила метрологии. Согласно науке ключевые данные НЕ вычисляются. Потому, что это снижает надежность. Есть варианты сбоя.
А вы внешние данные пытаетесь пристроить как ключевые. Увольняют и за меньшее.
.
"Ключи" во фреймах - это синхрослова, длиной 12 бит, записанные на первой позиции в каждом сабфрейме. Плюс, номер фрейма, записанный в заданной позиции относительно первого синхрослова. Плюс, время UTC (если таковое имеется, от GPS), или время GMT (если UTC отсутствует), записанные в каждом фрейме, и тоже, на позиции, определяемой производителем DFDAU в документе под названием Data Frame Layout (DFL). Этих записанных данных (плюс DFL), вполне хватает, чтобы программно преобразовать записи FDR в связанный с истинной временнОй шкалой поток исходных данных в "инженерных единицах" (engineering units), суть в единицах, в которых измеряется конкретный параметр.
.
Никаких прочих, выдуманных Вами и г-ном PPL, временных "меток", в словах фрейма не имеется. Я это могу доказать документально, а Вы - можете, ровно также, доказать обратное?
Цитата: iz_kirova от 26.10.2019 00:03:10...Частота ваших событий 0,25Гц. За это время специалист может разобрать вас на запчасти. Боинг за 4 секунды пролетит километр. Дружите с головой?...
.
Каких, "моих событий"??? Вы о чём??? Слушайте меня внимательно, и больше не лепите чепухи к моему честному
имени.
.
4 секунды - это длительность записи фрейма в поток данных (не на носитель FDR
! Что там делается, непосредственно в FDR - дело третьестепенное), то есть, временнОе "расстояние" между первыми синхрословами двух соседних фреймов. "События" же, суть параметры, прописанные в DFL, записываются во фрейме
в хронологическом порядке, с заданной частотой опроса соответствующего "пина" на входе DFDAU. Для большинства параметров, эти события попадают в каждый фрейм, в количестве от 1 до 32, равномерно распределённых по каждому сабфрейму. Примерно, вот так:
.
.
По факту, именно такую "карту" и рисуют разработчики DFDAU при составлении DFL, кропотливо раскидывая список заданных параметров по каждому сабфрейму. Для "медленных" же параметров (вес самолёта, дата, год) существует ещё и цепочка из 16 суперфреймов, в которых они записываются циклически, и тоже на заданных позициях.
.
Поэтому, довольно нелепо выглядят все Ваши последующие сентенции:
Цитата: iz_kirova от 26.10.2019 00:03:10Ваша система не запишет, например, удары при посадке. Не сможет их различить. Сольются в один. У вас квантование 4 секунды.
...Вообще, осознали бы частоту шины данных - вот показатель реальной скорости жизни контроллера FDR и его событий. И то - заниженный на несколько порядков ради надежности. 4 секунды - это годы
.
Цитата: iz_kirova от 26.10.2019 00:03:10Предлагаю ознакомиться с порядком записи данных на носитель и не писать глупости.
.
Занятно. Я ровно так же, оцениваю то, что Вы наваяли ниже.
Цитата: iz_kirova от 26.10.2019 00:03:101. Данные пишутся пакетами. Поэтому события не фиксируются штучно. Ферштейн? Пишется сразу пакет - ваш фрейм.
.
Ошибаетесь, изначально речь шла о записи фреймов в модуле DFDAU, отчего Вы перескочили на "носитель"?
.
.
Как видите, DFDAU, комплектуя фреймы из входящих данных, производит
непрерывный последовательный поток данных, пересылаемый в FDR со скоростью шины 717. Ровно такой же,
непрерывный поток данных пересылает в микроконтроллер FDR по классической последовательной шине SPI и микросхема, картинка из описания которой приведена выше.
.
Не вижу никаких преимуществ, если сначала в буферную память FDR,
со скоростью шины SPI, заносится некий блок данных, который потом, за микросекунды, записывается в твердотельную память, а далее... опять продолжается медленное заполнение буфера. Реальная скорость-то, записи, в конечном счёте, будет равна реальной скорости шины SPI, то есть шины 717, и что же? Понтов ради, -
данные пишутся, видите ли, пакетами... - если только.
Цитата: iz_kirova от 26.10.2019 00:03:102. Время записи пакета - миллисекунды или микросекунды. Элементарный подсчет показывает нулевую вероятность обрыва записи на середине пакета. Питание исчезнет или до или после.
.
А если питание исчезнет в процессе заполнения буферной памяти, описанной выше? Никакой разницы, пакетная запись ли производится, либо побитовая, но запишется абсолютно одинаковая последовательность битов, это очевидно.
Цитата: iz_kirova от 26.10.2019 00:03:103. Сбой электропитания непосредственно при записи данных будет иметь интересные последствия. Но вероятность события нулевая. Достаточно поставить на питание емкость по-более. Или конструкторы опять зажилили 50 центов?
.
См. замечание выше.
Цитата: iz_kirova от 26.10.2019 00:03:104. Поскольку запись циклическая, а данные цифровые - вы не сможете выделить конец записи в поврежденном пакете из "подложки" предыдущих данных.
.
См. замечание выше. Природу - не обманешь.
И в том, и в другом, случаях, потеряна будет какая-то,
совершенно идентичная, часть данных, которая будет вырвана из непрерывного потока данных, следовавшего по шине 717. "Склеивание" же будет элементарным, нам будут известны номера двух целых фреймов, а также синхрослова "до" и "после" сбоя питания, поэтому сохранившиеся обрывки без проблем станут на своё "место". То есть, будут идентифицированы, и в пространстве DFL, и во времени.
.
А так, хочу известить Вас, что и система электропитания Боинга 777, вообще, а системы FBR (Fly-By-Wire, если что), в частности, многократно резервирована. Так что, фатальный "сбой" питания маловероятен, вся система DFDRS, согласно нормативным требованиям, должна без проблем переносить отключение питания длительностью 0.2 сек.
Цитата: iz_kirova от 26.10.2019 00:03:10Ну и остальное у вас на таком же техническом уровне.
.
Я знаю, но всё равно, спасибо, за напоминание. Приходится обходиться, тем, что есть...
Зато, какой простор для совершенствования!