log ARINC UA93: MsgLen, ULBLK, NAK e altri ragionameti (in libertà)

MsgLen, ULBLK, NAK e altri ragionameti in libertà. Ossia altri dubbi da sviscerare e una traccia di condotta da seguire...

A differenza di tutti i miei precedenti articoli, utilizzo questa volta questo spazio non per elencare fatti o dubbi o notizie supportate da link alle documentazioni, ma per cercare ben più banalmente di fare "quattro chiacchiere".

"quattro chiacchiere" innanzitutto con me stesso. Come un attimo di break, per riprendere fiato, per cercare di vedere meglio.

Chi è abituato a leggere i miei articoli sa che son solito appoggiare le mie parole a documentazione e che ben raraamente mi lascio andare a "voli pindarici". Sa inoltre che non ho mai avuto problemi a correggere le cose da me scritte ogni qualvolta che nuova o più approfondita documentazione mi sia passata tra le mani o mi sia stato fatto notare uno o più errori.
Lo ribadisco: fare ricerca non è un gioco a punti. Non ci sono medaglie in palio e non si vince nulla.

Solo di fronte ai primi documenti di quella che possiamo chiamare "teoria ACARS/Planes Swap" (i Log dei printouts di Ballinger e le relative interviste della FBI a Winter e Knerr), quello che fino a prima era "solo" la somma di tanti "fastidi logici ad elevato tasso di improbabilità" e tessere del puzzle che non si incastravano (se non con forzature enormi), assumeva pienamente la forma riconoscibile e documentata di un pattern al quale non si poteva evitare di prestare attenzione. Grande attenzione.

Ora però, con il rilascio dei log Arinc di Warren Stutt e con il circolare di pezzi estratti dalle specifiche Arinc 618-5, questo solido pattern sembra vacillare. Anzi: vacilla.

Eppure:
diverse "incongruenze" a proposito sia di tali log sia dei ragionamenti che gli son stati cuciti addsso sono già emerse.
Nulla di comprovante.
Nulla che non possa avere la sua spiegazione logica (anche se sovenete per nulla facilmente comprensibile o pienamente razionale).

Altre possibili "incongruenze", ad esempio, ho avuto modo di notarle in questi giorni (anche se ancora non ho pubblicato alcun articolo in merito);

*la prima*
ad esempio:
- rapporto (di eguaglianza?) tra i valori presenti nei campi che indicano la lunghezza delle trasmissioni [ DL MsgLen - ADNS MsgLen - UL MsgLen ] e il numero di caratteri effettivamente presenti nei messaggi [ Message Text ]...sia che consideriate caratteri anche i tag del protocollo [ , , , , etc etc].
Normalmente per il campo DL MsgLen, abbiamo una differenza di 4 caratteri rispetto al campo Message Text decurtato dei tag.
Tale valore aumenta solo nei messaggi in downlink relativi a comunicazioni di informazione dell'aereo vero e proprio.

*la seconda*
Inoltre:
- su 96 comunicazioni ULBLK ci sono ben 59 , pari ad oltre il 61%
- su 356 comunicazioni in DLBLK ci sono 183 , pari ad oltre il 51%

Possibile che un così collaudato e diffuso sistema di comunicazioni sia così tanto "ballerino" e inaffidabile?

O invece come ben spiega il documento della Boieng "PegasusSRO":

Figure 5 - Uplinks [NOTA: SP= Service Provider]
Step....Description
1.......ATC sends message to SP

2.......SP sends message ACK to ATC [SP returns msg with reason if uplink cannot be formatted]

3.......SP breaks message into blocks if necessary, then sends block to Airborne Communications Management function

4.......Airborne Communications Management function sends block ACKs to SP [Airborne Communications Management function sends NAK if BCS fails]

5.......Airborne Communications Management function re-assembles blocks if message is a multi-block message, then sends LDU to Airborne ATS application system
[Airborne Communications Management function sends reject to SP if uplink is undeliverable]

6.......Airborne ATS application system sends link layer ACK to Airborne Communications Management function
[Airborne ATS application system sends NAK if CRC fails or if the msg is larger than 2 LDUs]

7.......SP sends MAS to ATC after all blocks are ACK'd by the Airborne Communications Management Function. [SP returns msg with reason if uplink was undeliverable]

la presenza del valore non significa affatto che la trasmissione non sia stata fisicamente ricevuta, ma solo che non sia stata ricevuta in maniera corretta (errore di CRC o di BSC), e che tale errore appunto sia stato segnalato a terra dalle Airborne Communications Management Function del FMC ?
NOTA: ho riportato l'esempio solo di Uplink, ma per il Downlink non cambia

Vorrà dire qualcosa tutto ciò? Il secondo punto indubbiamente avrebbe un'importanza da peso massimo. Per il primo, non so e non credo.


Ma non e questo il punto dell'articolo in questo momento.
Quello che volevo segnalere è come, specialmente in questo momento, giungere a conclusioni affrettate (in un senso o nell'altro) sia una cosa errata.

Inutile negarlo: dubbi (in un senso e nell'altro) ci sono.
E quindi, a volte, è corretto assumere un approccio meno di impatto e più ragionato.
Per fare questo, credo che mi comporterò cercando di spezzettare il più possibile l'argomento. A volte magari solo con micro articoli dove segnalare "punti fermi" o "inevitabili dubbi".

Tali articoli potranno quindi alle volte apparire come "micro" o "lunghi pipponi" o "slegati tra loro" o "forieri di dubbi e privi di certezze"; A volte potranno anche essere in parte duplicati di articoli precedenti: insomma un pò come una sorta di diario pubblico con le pagine riempite di appunti/ipotesi/ragionamenti/dati.
Una traccia di impronte che potrà essere di aiuto (o meno) ad altri ricercatori e a me stesso.

Tali articoli, per non fare troppa confusione, saranno etichettati con una immagine differente rispetto a quella usata per UA93 specificatamente.
Inoltre faranno tutti riferimento al Tag: "Research Sections"

Starà al lettore, tanto quanto a me, giungere alla fine a determinare una conclusione.

...Torna alla HOME