Цитата: PPL от 15.11.2019 14:45:17Отрадно, что Вы разобрались, и изменили свое утверждение, что 'запись идет одновременно с получением'.
.
Немного поразмыслив
, и в силу того, что Вы, по сути, остаётесь на незыблемых позициях, относительно собственных представлений по фундаментальным основам записи данных в параметрическом самописце, решил, пока Вы не имеете времени на форумные дискуссии, более детально описать, как мне видится, Ваши заблуждения в этом вопросе. Попутно, буду комментировать и Ваши ошибочные выводы по поводу содержания моих суждений.
.
С последнего, (см. выше
пометку в цитате) и начну.
.
Скрытый текст
Как я уже отмечал в предыдущем посте, Вы, воленс-ноленс, но исказили мою цитату из документа производителя FDR (...полётные данные, поступающие по шине 717,
записываются по мере их поступления в FDR...).
.
Я так понимаю, что "...
записываются по мере их поступления...", относящееся к "полётным данным", в толковании Honeywell, означает поочерёдную запись слов, содержащих текущие (на момент извлечения выборки на соответствующем входе DFDAU) значения конкретных параметров .
.
Хотя бы, даже в силу этого, мне не надо "
изменять своё утверждение" -
оно не моё, и я, априори, не в силах его "
изменить", да и оно - ну никак - не могло быть ложным, так как его сформулировал сам производитель. Согласитесь, кому,
как не ему, дОлжно знать, лучше всех нас, как функционирует его изделие, и в какой форме довести до потребителей своё "знание".
.
Но это ещё не всё, цитата из документа Honeywell была опубликована мной
05 ноября 2019, 15:53:19, но задолго до неё,
26 октября 2019, 22:47:36, я, "предвосхищая" вероятные наезды
, предусмотрительно вывел физический процесс записи слов за рамки своих рассуждений:
.
Цитата...4 секунды - это длительность записи фрейма в поток данных (не на носитель FDR! Что там делается, непосредственно в FDR - дело третьестепенное), то есть, временнОе "расстояние" между первыми синхрословами двух соседних фреймов. "События" же, суть параметры, прописанные в DFL, записываются во фрейме в хронологическом порядке, с заданной частотой опроса соответствующего "пина" на входе DFDAU.
...Исходя из требований FAA, обязывающих производителей FDR обеспечивать их работу в течение 0.2 сек после потери питания, этого периода вполне достаточно, чтобы скинуть все буферные данные самописца в его твердотельную память.
.
.
Как видите, никакой прямой аналогии с понятием "
одновременность" вовсе не присутствует в моих представлениях о хронологической связи
физического процесса записи в сегменты твердотельной памяти какого бы то ни было электронного устройства, и,
чего бы то ни было, поступающего на его вход.
.
Вопрос закрыт.
Цитата: PPL от 15.11.2019 14:45:17Не покатит, и я же объяснил почему: такая схема не отловит пропадание одного или нескольких бит, это же очевидно.
Содержимое фрейма будет частично побитово сдвинуто влево, вся структура в кашу.
Самосинхронизируемые протоколы так не делают.
.
Возможно, мы с Вами говорим о совершенно разных "
схемах".
.
Ваша: "...
ждать фронта/спада для различения бит - что для FDR не подойдёт, в нижнем протоколе не даст отловить пропуск бита или нескольких...", вовсе не похожа на ту, которая приведена, в монографии Сухмана, Бернова и Шевкопляса "Синхронизация в телекоммуникационных системах" (п. 9.2 "Выделение синхросигнала и данных схемой на сдвиговых регистрах"), и ссылается на патент США № 5.825.834. Там приведена конкретная частота синхронизации (12 МГц) и кратно связанная с ней частота G (96 МГц), что вовсе не важно, думаю, понимаете... :
.
Сам патент (обратите внимание, текущее число "практических применений" - application - 542856) :
Не очень понятно, о каком "отлавливании пропуска бита или нескольких" Вы беспокоитесь, но, судя по изложению параграфа 9.2, в "моей" схеме такой проблемы не существует, иначе, достойные авторы монографии непременно бы её отметили.
Из произвольного состояния (считайте, при включении двигателей самолёта, и при запуске работы DFDAF) схемы "отлавливается" первый же положительный перепад входящего сигнала (DIN), и далее, в самом худшем случае, устойчивое синтезирование синхросигнала SYNC устанавливается за 4 периода генератора G, что составляет полпериода следования импульсов SYNC (см. график синтеза этого сигнала на картинке под спойлером):
.
.
Факт, что, что-то, и где-то, там, вверху, "пропадает", и "сдвигается в кашу", мне, например, вовсе не очевиден. Растолкуйте, если пожелаете.
Цитата: PPL от 15.11.2019 14:45:17По 'вычислениям' времени событий по сдвигу от начала четырех секундного фрейма.
.
Корректнее, - не времени "событий", - а времени получения выборок каждого из конкретных параметров, входящих в документ производителя DFDAU (DFDAF) Data Frame Layout (Структура данных фрейма). Конечно, можно назвать "событиями", именно, считывание этих конкретных выборок из регистров входного буфера модуля, но в словах-то фреймов, фиксируется не эти события, а, согласно DFL, значения параметров, которые, лишь в ограниченном количестве случаев, важны, в смысле фиксирования, действительно, неких событий, с ними связанных. Например, один из элементов бинарного множества состояний (значений) параметра "Положение тангенты УКВ-передатчика КВС", достаточно элементарно (и содержательно!) ассоциируется с событием выхода КВС на связь с диспетчерами УВД.
Цитата: PPL от 15.11.2019 14:45:17FDR фиксирует не независимые события.
.
FDR фиксирует дискретизированные значения параметров полёта, и всю их совокупность, в частности, аналоговое подмножество, очень сложно относить к "событиям". Поэтому, напрасно Вы используете эту дефиницию, рациональнее применение понятия "значение параметра".
Цитата: PPL от 15.11.2019 14:45:17Худшая точность же определения времени в Вашем варианте - размер фрейма, 4 секунды. Развитие аварийных ситуаций, которые обязан фиксировать рекордер, такая точность не даст зафиксировать.
.
FDR "
обязан фиксировать" только значения параметров (mandatory parameteres), которые, и сами, и частота их выборок (sampling rate), и диапазон записываемых значений (recording range), и требуемое разрешение (resolution), определяются требованиями авиационных регулирующих организаций (для Боинга - US
Federal Aviation Administration (
FAA)). На текущий момент, таковых параметров -
88.
.
В обязательный перечень могут добавляться и собственные, производителя самолёта, параметры (non-mandatory parameters), число которых, иногда, превышает и 1000. Понятно, что вся эта фигня вовсе не берётся с потолка, за долгие годы расследований АП, и у расследователей, и у регуляторов, и у производителей (с частной целью, работающей на перспективу - сбор максимальной информации о работе агрегатов и устройств самолёта), выработались чёткие алгоритмы составления этого расширенного перечня.
.
Исходя из изложенного, констатируем, что нет никаких - "
Ваших", "
наших" и
прочих - вариантов. Он - единственный и обязательный, требующий создания множества "нитей", - хронологических последовательностей выборок каждого списочного параметра, - сливающихся в единый мультиплексированный поток (stream), следующий, согласно заданному стандарту ARINC 717, прямиком на запись в FDR. :)
.
Реализуя вышеописанные "обязанности" стандарта, DFDAF Боинга непрерывно и последовательно, с заданной, в единицах
wps, скоростью передачи слов, считывает входные регистры (регулярно обновляемые), и пересылает их содержимое, цифровые значения параметров полёта, скомпонованные во фреймы, в шину 717, в той последовательности, которую ему предписывает DFL разработчика FDRS.
.
Эту несложную цепочку логически связанных суждений я излагаю не в первый раз, почти с самого начала обсуждения особенностей записи параметров полёта. Изначально, они базировались, исключительно, на общих соображениях, связанных с довольно скромными познаниями в этой области. Теперь же, я готов отвечать, за каждое из них, опираясь на документы, и регулирующие, и производителей, как Боинга, так и FDR.
Цитата: PPL от 15.11.2019 14:45:17Вычисления бессмысленны, вместе со значением необходимо хранить и временную метку события. Именно от того, что данные определяются позицией в суперфрейме.
.
Для того, чтобы было понятно, о чём я веду далее речь, ниже, под спойлером, представляю Вашему вниманию скрин "выписки" из стандарта ARINC 647-A1, который описывает структуру и содержание электронной документации, которая должна сопровождать систему записи параметров полёта, включающую в себя DFDAU (DFDAF) и FDR. То есть, по сути, эта электронная форма (XML-файл) документации заменяет печатную, ранее, форму DFL. В "выписке" изложена информация о новом элементе в списке компонентов, описывающих характеристики каждого параметра,
Acquisition Time Offset, которая, практически, один в один, совпадает с моим описанием, как Вы выразились "бессмысленных вычислений"
:
.
Цитата...This item describes the relative acquisition time of the parameter sample in a subframe, in relation to the time representing the start of the subframe...
Вольный перевод: ...Этот элемент описывает относительное время получения выборки параметра в сабфрейме, по отношению ко времени начала его отсчёта...
.
То есть, Вы, определённо, упускаете из виду, то, что
каждый параметр фрейма имеет сугубо индивидуальное время своего считывания из соответствующего входного регистра DFDAU, которое, самым естественным образом, отличается от аналогичного времени считывания любого из других параметров. Именно, поэтому местоположение (адрес) каждого слова, как я уже неоднократно сообщал, и называют
time-slot address -
адрес временнОго интервала. Того самого, который и был отведён для считывания параметра, имеющего этот адрес.
.
Сам обещанный скрин:
Цитата: PPL от 15.11.2019 14:45:17Стружка в масле, повышение температуры движка, вертикальный толчок в 2.5g ,включение ППС и отключение генератора, все за 4 секунды, что за чем было? Что следовало за чем?
.
Надеюсь, с учётом вышесказанного, у Вас уже не будут возникать вопросы подобного рода. И "стружка в масле", и "повышение температуры движка" etc etc, каждый из параметров имеет свой собственный
time-slot, поэтому хронология любого события, связанного с ними, вполне себе индивидуальна, и легко дифференцируется от всех прочих.
.
Как, впрочем, эта
индивидуальная хронология выборок конкретного параметра также легко отображается и на шкале времени UTC, так как нет никаких проблем посчитать для неё этот самый
Acquisition Time Offset, по отношению к time-slot параметра
Time, имеющего железобетонную привязку к своему значению - UTC-времени извлечения этого параметра из входного регистра.
Цитата: PPL от 15.11.2019 14:45:17Непонятно, ради чего вы загнались на этой теме.
.
Истины ради, ничего более.
Отредактировано: meovoto - 19 ноя 2019 23:58:04