Indianhead, Imperial e le mappe aeree di ZOB

mappe di ZOB (2003/2004), comunque utili per farsi una idea più precisa...

Un articolo, semplice, più che altro per archiviare informazioni che possono tornare utili anche ad altri researchers.
Un articolo che, fondalmentalmente ma non solo, propone le mappe relative a ZOB (le mappe sono aggiornate al periodo 2003/2004; in particolare per quello che riguarda le frequenze), tenendo conto che "Indianhead / Imperial space was where UA 93 was located when he crashed".

Tra l'altro, nel su linkato MFR si legge che: "Originally, she [NdA: Linda Justice, ATC per l'Area 6 del Imperial Sector l' 9/11] tried to hand him off to Washington Center because she thought he was going back there and then finally she received a report of a plane flying at 8,000 feet".

.

Comunque, qui potete veder ele mappe aeree

ZOB Low Area's


ZOB Low Sectors


ZOB Low Sectors with Freqs


ZOB High Area


ZOB High Sectors


ZOB High Sectors with Freqs


Come si sà, a transponder spento non vengono trasmesse dall'aereo ai radar secondari in paticolare le informazioni relative all'altitudine (non che l'aereo scompaia dagli schermi);

... e nella timeline relativa a UA93, come elaborata dalla 9/11 Commission, si legge:

Leggi l'articolo... | ...Torna alla HOME

RESEARCH SECTIONS - I "caratteri speciali" presenti nei log ACARS: elenco e spiegazione - AGGIORNATO IL16.5.12

Un documento FAA/ARINC ci spiega il significato dei "caratteri speciali" che appaiono nei log ACARS della ARINC (rilasciati da Stutt o letti da Winter o in parte presenti in quelli di Ballinger)
- POST AGGIORNATO IL 16.5.12

Ho trovato da poco in rete questo documento ufficiale FAA/ARINC, in cui oltre ad essere illustrati i risultati di uno stress test per i tempi di consegna delle comunicazioni ACARS, vengono alnche elencati e spiegati i "caratteri speciali" che appaiono nei vari log (" :; " " ~1 ", " ~2 ", " DEL ", " Q0 ", etc etc )

Il test eseguito nel corridoio NYC-DCA-CHI, perfettamente pertinente con quanto di interesse per UA93.
Il test è stato eseguito e il documento scritto, nel 1995. Quindi in data certamente antecedente il 9/11, e antecedente alcune migliori apportate alla funzionalità del sistema.

Tale documento è reperibile a questo indirizzo: http://ntl.bts.gov/lib/1000/1200/1290/tn95_66.pdf

I "caratteri speciali" sono:

Label	Sublabel	Uplink/Downlink	Message Type
DEL	n/a	U	General Acknowledgment
:;	n/a	U	Autotune to New Frequency
RA	~1	U	Display Message
RA	~2	U	000I Dump
RA	~3	U	Memory Dump
RA	~4	U	Loop-Back Test
51	n/a	U	GMT Update
54	n/a	U	Voice Go-ahead
DEL	n/a	D	General Acknowledgment
NAK	n/a	D	Non-Acknowledgment
H1	DF	D	DFDAU Message
Q0	n/a	D	Link Test
Q5	n/a	D	Unable to Deliver Message
RB	~2	D	000I Dump
RB	~3	D	Memory Dump
RB	~4	D	Loop-Back Test Response
52	TXT	D	Free Text Message
51	n/a	D	GMT Update Request

":;", "Q0", "Q5", "~1", "~2" rivestano indubbiamente una netta importanza ai fini di una completa e corretta e approfondita analisi e comprensione dei log delle comunicazioni ACARS (senza dimenticarsi appunto che a Winter, della UAL, la FBI aveva sottoposto per la lettura e la corretta interpretazione dei dati, proprio una versione "sanitized in text and times" esattamente come fare un filtro ai log rilasciati da Stutt, selezionando solo i log relativi ad UA93 pr un determinato periodo di tempo).

Approfitto inoltre per segnalare la "traduzione" di alcuni termini (intestazioni di campo nel file rilasciato da Stutt) quali:

BEP = Back-end processor [link1 link2 link3]

AJPSBcnt = cnt probabilmente è l'abbreviazioni "count", conteggio, mentre la parte precedente è invece indubbiamnte l'acronimo per:

AJPS = AFEPS journal processing system [link1 link2]

AFEPS = ACARS front-end processing system [link1 link2]

Altri termini come UBI/DBI/ULMSG/DLMSG/ACK/NAK et similia, dovrebbero ormai essere completamenti noti a i più, e quindi sorvolo.

------AGGIORNAMENTO DEL 16.5.12---------

Ed ecco un altro link a cui far riferimento, che porta un altro pò di informazioni utili a decodificare i codici/caratteri presenti nei messaggi ACARS (rilasciati da Warren).

LINK: http://www.wavecom.ch/onlinehelp/WCODE/default.htm#!WordDocuments/acars.htm

Al succitato indirizzo, si può apprendere come: "ID and uplink test message transmitted at regular intervals from ground stations" siano chiamati "SQUITTERS".
Nei rawdata dei messaggi ACARS, si identificano dalla sigla:
SQ

C'è la conferma che il codice:
:; faccia riferimento al transceiver auto tune

C'è anche l'indicazione relativa alla sincronizzazione:
2 characters SYN, SYN
Questa è presente nei file di Stutt, nella versione in PDF, subito dopo l'indicativo del tipo di trasmissione (ULBLK o DLBLK). Ed è correttamente espressa nella forma indicata ( S=31 D=21 )

E c'è anche la spiegazione al carattere numerico che precede i messaggi, e che sta ad indicare la modalità di trasmissione ACARS (BROADCAST o NON BROADCAST)

"ACARS communications are divided in Category A and Category B".
Using Category A, an aircraft may broadcast its messages to all ground stations. This is denoted by an ASCII "2" in the Mode field of the downlink message

Using Category B an aircraft transmits its message to a single ground station. This is denoted by an ASCII character in the range "@" to "]" in the Mode field of the downlink message.

The ground station may use either "2" or the range "‘" to "}" in the Mode field. All ground stations support Category A, but may uplink "‘" to "}" in the Mode field".

...e così abbiamo la certezza (relativa, visto che si basa sui log rilasciati da Stutt sui quali molti dubbi di autenticità si continua a nutrire) di poter identificare quante e quali trasmissioni siano state inviate in modlità broadcast e quali no.

Leggi l'articolo... | ...Torna alla HOME

RESEARCH SECTIONS - perchè possiamo essere sicuri che il documento BOEING CAGE CODE 81205 doc n° D926T0280, sia utilizzabile nell’analisi dei log ACARS

Perchè possiamo essere sicuri che il documento BOEING CAGE CODE 81205 doc n° D926T0280 / PegasusSRO, sia utilizzabile nell’analisi dei log ACARS...

In questo mio precedente articolo abbiamo acclarato che N591UA / UA93 era dotato di FMC (Flight Management Computer) tipo "PEGASUS" (firmware'98-'99-'00, non ha nemmeno importanza).

Abbiamo quindi accennato e visto come il FMC sia il computer di bordo dedicato alll’automazione di tutta una vasta serie di operazioni.

Da qualsiasi pubblicazione del settore, dalla visione dei log Arinc pubblicati da Warren Stutt, dal precedente articolo, e anche perfino da Wikipedia: abbiamo inoltre la conferma che:
il sistema Acars è un datalink digitale dedicato alla trasmissione di messaggi relativamente brevi tra aerei e stazioni a terra.

"Aircraft Communications Addressing and Reporting System (ACARS) is a digital datalink system for transmission of short, relatively simple messages between aircraft and ground stations via radio or satellite".

On the aircraft, the ACARS system was made up of an avionics computer called an ACARS Management Unit (MU) and a Control Display Unit (CDU). The MU was designed to send and receive digital messages from the ground using existing VHF radios.

On the ground, the ACARS system was made up of a network of radio transceivers, managed by a central site computer called AFEPS (Arinc Front End Processor System), which would receive (or transmit) the datalink messages, as well as route them to various airlines on the network.

Forti dell'irrefutabile informazione circa la versione del FMC installato a bordo di N591UA / UA93 (la PEGASUS), dobbiamo adesso accertarci della completa validità dell’utilizzo del documento BOEING CAGE CODE 81205 doc n° D926T0280.pdf" [ LINK 1 .pdf - LINK 2 .doc ], senza tema di poter essere smentiti circa l'affidabilità di tale fonte documentale.

A tale proposito, notiamo innanzitutto che:

A) tale documento (e quindi conseguentemente che la versione del FMC a bordo di UA93 fosse proprio a Pegasus '00) è portato ad esempio (anche se in maniera non completa) dallo stesso da booNyzarC nella presentazione della sua teoria:

booNyzarC:

[ LINK: http://www.unexplained-mysteries.com/forum/index.php?app=blog&blogid=3114&showentry=24415 ]

Boeing:

B) Ma se nel dettaglio, il documento BOEING CAGE CODE 81205 doc n° D926T0280 fornisce molte informazioni utili a meglio comprendere il mondo dello scambio comunicazioni aereo/terra - terra/aereo e sulle comunicazioni ACARS (di nostro interesse), riporta però anche la seguente affermazione:

The scope of this document shall be limited to the description of the Air Traffic Services Function as it relates to the implementation in the 757/767 (Pegasus ‘00) FMC FANS 1 Package. The functions of FANS 1 to be considered are:

* ATS Facilities Notification Function (AFN) per ARINC 622-1;
* Automatic Dependent Surveillance (ADS) per ARINC 745-2;
* Two Way ATC Datalink (ATC DL) per RTCA DO-219; and
*Datalink Function per ARINC 429 Supplement 13, ARINC 619, ARINC 724B, ARINC 741, ARINC 716, ARINC 618, ARINC 622-1, and ARINC 620

This document will not cover the requirements associated with the Airline Operational Communications Datalink (AOC DL). This document will also not cover the requirements or integration of the Global Navigation Satellite System (GNSS) as it does not participate directly in the ATS function. Ground-to-ground ATS communications are also beyond the scope of this document.
[ LINK 1 .pdf - LINK 2 .doc ]

Ossia che il boeing cagecode xxxx non tratta dei “requirements” relativi alle comunicazioni ACARS di tipo AOC.

Già sappiamo che i messaggi ACARS (datalink message types) sono di tre tipologie simili ma distinte:
- Air Traffic Control (ATC)
- Aeronautical Operational Control (AOC)
- Airline Administrative Control (AAC)

ATC messages are used to communicate between the aircraft and Air traffic control. These messages are defined in ARINC Standard 623. ATC messages are used by aircraft crew to request clearances, and by ground controllers to provide those clearances.

AOC and AAC messages are used to communicate between the aircraft and its base. These messages are either standardized according ARINC Standard 633 or defined by the users, but must then meet at least the guidelines of ARINC Standard 618. Various types of messages are possible, and these include fuel consumption, engine performance data, aircraft position, as well as free text data

Orbene, il fatto che tale documento non tratti direttamente dei “requirements” associati alle comunicazioni AOC DL, ossia dello scambio di comunicazioni tra Compagnie ed Aerei ( nostro principale oggetto di interesse ), non implica che le informazioni circa le modalità fisiche, logiche e protocollari di trasmissione delle trasmissioni ACARS descritte nel Boeing Cage-Code 81205 num.D926T0280, non siano valide anche per tali comunicazioni.

C) Anche esse infatti “must then meet at least the guidelines of ARINC Standard 618” e quindi a tutti gli effetti fanno riferimento alla stessa architettura di funzionamento.
Nemmeno i debunkers hanno messo in dubbio questo indiscutibile fatto, dato che come su dimostrato, non han avuto nessun dubbio nel utilizzarlo per le loro "dimostrazioni”,citandolo e pubblicandone degli screenshots.

D) Inoltre, al punto 5.2 (pag. 16 del documento in pdf) si legge espressamente:

The datalink function allows for the exchange of data among the various parts of the datalink applications, which are distributed among the aircraft and the ground host computers....[snip]...The datalink function is generally described in...[snip] ...ARINC 618 (air-to-ground)...[snip] ...ARINC 620 (ground-to-ground).
[ LINK 1 .pdf - LINK 2 .doc ]

Ciò ad ulteriore dimostrazione (oltre che booNyzarC abbia fatto corretto riferimento alle specifiche 618 e 620) della correttezza di ricorrere a questo documento come fonte documentale: dove mentre le specifiche Arinc 618 e 620 descrivono nel dettaglio il protocollo interno ARINC delle comunicazioni (anche AOC), questo documento ne specifica l’architettura d’ambiente.

E) Come ben si legge nel documento stesso: tale pubblicazione è del 2000 (12 maggio 2000), quindi certamente antecedente la data dell’undici settembre 2001 (di oltre un anno).

Quindi, in definitiva, a questo punto siamo arrivati ad avere almeno due punti fermi validi nel proseguio delle analisi relative ai log ACARS di UA93/N591UA::
- presenza di FMC PEGASUS
- BOEING CAGE-CODE 81205 doc n° D926T0280, utilizzabile

Leggi l'articolo... | ...Torna alla HOME

RESEARCH SECTIONS - Il FMC (Flight Management Computer) di UA93: il "Pegasus"

A proposito del FMC di UA93: un articolo propedeutico ad affrontare con maggiore sicurezza il documento "BOEING CAGE CODE 81205 doc n° D926T0280.pdf" / "PegasusSRO.doc"...

Che uno dei quattro aerei coinvolti negli attacchi terroristici dell’11 settembre 2001 fosse il volo della United Airlines UA93, è informazione ovviamente nota.

Che il Tail Number, ossia il codice di identificazione, di tale aereo fosse N591UA è anche questa un’informazione nota.

Che la versione software del FMC (Flight Management Computer, il computer di bordo specializzato per l’automazione di tutta una vasta serie di operazioni), alla data dell’11 settembre 2001, fosse la “Pegasus”, è già meno noto.

"The flight plan is generally determined on the ground, before departure either by the pilot for smaller aircraft or a professional dispatcher for airliners. It is entered into the FMS either by typing it in, selecting it from a saved library of common routes (Company Routes) or via an ACARS datalink with the airline dispatch center."

Adesso, dopo questo brevissimo accenno al FMC in generale, andamo a scoprirne di più nel dettaglio.
E più nel dettaglio vediamo che: per i Boeing 757 esistono 3 tipi di FMC:
- Basic
- PIP
- PEGASUS

[ LINK: BOEING ]


I FMC versione “Pegasus” permettono agli operatori l’utilizzo di software opzionale capace di accedere ad elementi del FANS (Future Air Navigation System)
[ LINK: http://biggles-software.com/software/757_tech/flight_management_navigation/fmc.htm ]

"With the Pegasus FMC, operators can choose optional software that enables elements of the future air navigation system (FANS). FANS functions provide operators with the ability to use advanced systems, such as global positioning system (GPS) sensors and satellite communications (SATCOM), to take full advantage of new communication, navigation and air traffic management systems for more efficient routing and decreased trans-oceanic traffic separation."
[ LINK: http://www.boeing.com/commercial/757family/pf/pf_300back.html ]

Interrogando il database della FAA verifichiamo che appunto N591UA era proprio un Boeing 757, per l'esatttezza 757-222

Dalla pagina del sito della Boeing relativa ai 757 della famiglia della serie 200, leggiamo sia di FMC sia di FANS:

"The 757-200 flight deck, designed for two-crew member operation, pioneered the use of digital electronics and advanced displays. Those offer increased reliability and advanced features compared to older electro-mechanical instruments.
A fully integrated flight management computer system (FMCS) provides for automatic guidance and control of the 757-200 from immediately after takeoff to final approach and landing. Linking together digital processors controlling navigation, guidance and engine thrust, the flight management system assures that the aircraft flies the most efficient route and flight profile for reduced fuel consumption, flight time and crew workload".

Di FMC sui Boeing 757 abbiamo dunque letto; andiamo adesso a verificare che la versione del FMC fosse la "Pegasus" (cerceremo poi anche di scoprire di quale release)

Per questo ci viene in aiuto il numero del 7 Settembre 1998 di “Aviation Week”, una rivista specializzata del settore aeronautico, che ci informa di come già alla data del Marzo 1998, la Honeywell avesse ottenuto i permessi di sicurezza e certificazione per l’installazione in conformità con le direttive vigenti, del sistema “Pegasus” per gli FMC; e che tali upgrade riguardassero appunto anche i Boeing 757 (e 767).

"Honeywell has been selected by more than 30 airlines from around the world, plus the U.S. Air Force, to supply its new-generation "Pegasus" flight management system (FMS) for their aircraft.

The Honeywell "Pegasus" flight management system earned its first FAA certifications March on the Boeing 757, 767 and MD-90 aircraft types, ushering in the long-anticipated era of Communication, Navigation, Surveillance/Air Traffic Management (CNS/ATM).

The Pegasus architecture, a key element of Honeywell’s WorldNav™ program, is designed to be used across multiple aircraft hardware platforms – Airbus A320 family, A330, A340; Boeing 757, 767, 717, MD-11 and MD-90. This represents the first time there has been this level of hardware and software commonality of a major system across aircraft types.
Airlines get FANS-1/FANS-A capability along with significantly enhanced system response times, greater operational reliability and increased navigation data base capacity".

Dunque “Aviation Week” ci informa di come la Honeywell avesse, nel Settembre 1998 (ben tre anni prima del undici settembre) già ricevuto ordini di acquisto del “Pegasus” da oltre 30 compagnie aeree.
Tra queste, ovviamente, c'è anche la United Airlines.

Ad ulteriore conferma e certezza che alla data del l’11 settembre i FMC dei 757 della United Airlines fossero upgradati alla versione “Pegasus”, ci sono anche parole scritte nel “Summary Report” del simposio tenuto dalla Boeing nell’ottobre del 2000 (dunque almeno un anno prima del undici settembre 2001):

e nel dettaglio:

"FMC. We use the P/N –127 and –945 (Pegasus) Flight Management Computers (FMC) on our 757 fleet"
[ LINK: http://www.smartcockpit.com/data/pdfs/plane/boeing/B767/misc/B767_Symposium_(2000).pdf ]

Ossia:
"usiamo sulle flotte di 757 FMC PEGASUS, di cui alcuni pezzi hanno serial number..."

Perchè queste informazioni sono importanti? Cosa ci garantisce la certezza di questa informazione?
Beh, ciò che fornisce è che nel momento in cui si va a leggere e analizzare il fondamentale documento: BOEING CAGE CODE 81205 doc n° D926T0280, sappiamo che non stiamo utilizzando un documento "svincolato" dalla storia di UA93/N591UA: Anzi!
E visto che si tratta di un documento (pubblicamente consultabile a differenza delle specifiche Arinc) strettamente relazionato ai log delle comunicazioni ACARS... era ed è bene essere certi che su tale documento si possa fare affidamento.

[ NOTA*1]
il doc "BOEING CAGE CODE 81205 doc n° D926T0280" in formato PDF, scaricabile a questo link:
http://www.boeing.com/commercial/caft/cwg/ats_dl/757-767_ATS_SRO.pdf
non sempre risulta a disposizione.
Lo stesso documento però, può essere scaricato in versione .DOC, a questo indirizzo:
http://www.overlookci.com/PegasusSRO.doc
[ FINE NOTA*1]

Il "Cage Code 81205" specificamente tratta del PEGASUS-00 (dove 00 indica l'anno della versione).
Siccome sappiamo che N591UA era un 757, siccome sappiamo che sui 757 i FMC erano "Pegasus", siccome abbiamo a disposizione il documento della Boeing relativo ai Pegasus 00, dobbiamo adesso accertarci (visto che non sappiamo con certezza quale versione/anno fosse quella installata su N591UA) se tra questa release e le precedenti vi fossero dei cambi così sostanziali da impedirci di poter fare completo affidamento sul documento a disposizione in relazione a UA93, oppure no.

per fare questo, basta andare a leggersi a fondo documento:
-la "APPENDIX F2" e
-la "APPENDIX F3"
che riportano appunto le differenze rispetto alle precedenti versioni ('98 e '99).

Come potete si può leggere dal documento e vedere negli screenshots, tali differenze non risultano impattatnti rispetto alle funzioni primarie del PEGASUS, permettendoci cosi di poter utilizzare tranquillamente il doc PEGASUS SRO come riferimento qualificato, quando si vanno ad analizzare i log ACRAS di UA93.

Leggi l'articolo... | ...Torna alla HOME

Acars/Arinc Research Sections - Chi paga il costo di mantenimento delle RGS

Acars/Arinc Research Sections: chi paga il costo di mantenimento delle Radio Ground Stations (RGS)...

Un'altra utile informazione relativa alle Radio Ground Station, ossia scopriamo chi paga il costo di mantenimento e gestione delle RGS.

*****CHI PAGA I COSTI DI MANTENIMENTO DELLE RGS*****

"Communications consists of air-to-ground data link and ground-to-air voice and data communications. The principal domestic pilot/controller communications are via VHF radio. The main data link which is in operation today is the Aircraft Communication Addressing and Reporting System (ACARS) data link. The ACARS data link ground system is run by ARINC and operates as a service principally to the airlines. Ground operation data link costs are funded by a "fee per message" paid by the users".

blabla... [snip]...
i costi di mantenimento e gestione delle RGS sono pagati da chi utilizza il sistema ACARS (le compagnie aeree principalmente dunque), al costo di "un tanto a messaggio"

Nota: è ovviamnete facile immaginare che le compagnie stipulino contratti annuali/decennali/etc per un numero "X" di messaggi, un pò come avviene per le grandi aziende con le compagnie telefoniche.

[ Link: http://bellsouthpwp.net/j/a/jacknadelman/jack-nadelman-resume/html/acars.htm ]

|| end section 1 ||

Leggi l'articolo... | ...Torna alla HOME

Acars/Arinc Research Sections - ACARS Management Unit (MU)

Research Sections ACARS/ARINC: un dato importante sul ACARS Management Unit...

Come preannunciato nel precedente articolo... ecco il primo post della categoria "research sections".
Da utilizzare come fonte e riferimento.

NOTA:
questo articolo subirà aggiornamenti, in quanto ogni ulteriore informazione relativa al MU, verrà qui di seguito aggiunta.

****ACARS Management Unit (MU)****

"The ACARS MU is the airborne communications management system that is responsible for the transfer of data between the airborne systems and the ground-based systems using the ACARS protocol."

il MU (Managemet Unit) è la parte computerizzata del sistema di gestione delle comunicazioni ACARS, INSTALLATA A BORDO DELL'AEREO, che è RESPONSABILE del trasferimento dei dati tra i sistemi a bordo e i sistemi a terra che comunicano tarmite il protocollo ACARS

"The ACARS MU can host Airlines Operational Control (AOC) applications that may have the need to send/receive data to/from the ground-based computer systems. It can also be connected to other onboard computer systems, such as the FMC (Flight Management Computer) which hosts ATC/AOC applications, to serve as a relay function for these computers for air-ground message transfer."

il MU può essere connesso al FMC, favorendo e fornendo una funzione di connessione per i trasferimenti dati aria/terra tra FMC e basi a terra

"As a communication processor, the ACARS MU can operate seamlessly in any flight phase without peculiarities in any phase. The ACARS MU selects which data link to use depending on the aircraft operating environment (e.g., terminal area versus oceanic). This selection typically is based on airline policy rather than data link performance. For example, although SATCOM provides virtually world wide coverage, it is used only when necessary as it is also the most expensive form of communication".

L'ACARS MU è un computer dedicato alle trasmissioni in grado di operare senza interruzioni in qualsiasi fase del volo. Automaticamnete sceglie quale sistema usare per meglio garantire la riuscita della comunicazione a terra, scegliendo se usare VHF, HF o SATCOM. Ma tale scelta normalmente è limitata dalle policy delle compagnie aeree. Infatti ad esempio le comunicazioni SATCOM pur foriere di maggior garanzia di consegna, costano di più e quindi vengono usate di meno.

[ Link: http://bellsouthpwp.net/j/a/jacknadelman/jack-nadelman-resume/html/acars.htm ]

||--end section 1 --||

Leggi l'articolo... | ...Torna alla HOME

UA93 - A disposizione uno strumento in .CSV con dati 84Th RADES, FDR, ARINC e UAL ordinati su base temporale

Rilascio di uno strumento di lavoro per UA93: dati "84th Rades + Fdr + log Arinc + log Ballinger" ordinati su base temporale...

Con questo articolo metto a disposizione un nuovo strumento di lavoro che può essere utile ad ogni ricercatore.

Si tratta di un file in .CSV, in cui ho aggreato alcuni salienti dati rilasciati da:
- 84Th RADES per UA93
- FDR UA93 (tramite il deocoder fornito da Stutt)
- Log ARINC UA93 (pubblicati da Stutt)
- LOG UAL Ballinger UA93

Tutti i tempi son stati convertiti in ET, tutte le informazioni sono state quindi ordinate su base temporale.

I dati che ho selezionato fanno riferimento a:

**84th RADES**:
- Time ET
- Mode C Altitude
- Decimal Latitude
- Decimal Longitude
- Latitude
- Longitude

**FDR**
- Time ET
- Subframe Counter
- ALTITUDE (1013.25mB) (FEET)
- PRES POSN LAT (DEG)
- PRES POSN LONG (DEG)

**LOG ARINC**
- Time Et BEPts
- FLoc
- BepStnName
- Target Stn
- Stn
- SSV
- Org TimeStamp 20010911
- Block Type
- NAK presence

**LOG UAL BALLINGER**
. Time [sent message]
- Time [elaborated/received]
- Time order num
- Scan order num
- Uplink/downlink
- CMD/AGM
- RGS
- Flag_31 ( STATE OF TRANSMISSION [ ??? ] *vedasi questo articolo )

Tale documento in . CSV è scaricabile a questo LINK


NOTA:
siccome i log UAl di Ballinger non presentano anche i "minuti secondi", sono stati inseriti come se tale valore fosse "00".

il campo "ACK presence" è una mia estrapolzaione della presenza o meno di tale valore nella colonna di riferimento

Leggi l'articolo... | ...Torna alla HOME

ACARS UAL BALLINGERS LOGS: analisi dai dati in .CSV

ACARS UAL BALLINGERS LOGS: analisi dai dati in .CSV...

Utilizzando il file "Ballinger_LINEAR_CSV.csv", messo a pubblica dispozizione in questo articolo, ho notato che i valori presenti nella colonna del "flag_31", possono suscitare nuovo interesse.

Tale colonna infatti, presenta valori degni di essere notati (e poi quindi compresi e interpretati).

Il "flag_31", per tutti i messaggi presenti, appare impostato a soli tre distinti valori: "blank" (inteso come assente, vuoto), "1" e "2".

Ciò che si può e deve notare è che:

- il valore "blank" per i messaggi in uplink [messaggi time order "2" 13:22; "11" 13:50; "12" 13:50; "13" 13:51; "14" 13:51;] sono tutti trasmessi con attivo il campo "AGM" (stampante)
- il valore "blank" per il messaggio in downlink [messaggio time order "1" 13:21;] è anch'esso trasmesso con attivo il campo "AGM" (stampante)

- il valore "1" appare per tutti i messaggi con attivo il campo "CMD" (monitor), eccetto che per la ultima comunicazione indubbiamente "non ricevuta/non inoltrabile"
- il valore "1" appare per messaggi che sicuramente son stati fisicamente ricevuti da UA93 (come ad esempio per il messaiio time order "3" 13:23)

- il valore "2" appare una ed una volta sola
- il valore "2" appare in riferimento ad un messaggio con attivo il campo "CMD" (monitor)
- il valore "2" appare solo in relazione alla comunicazione (messaggio time order "18" 14:20) che sicuramente non è stata mai ricevuta / mai inoltrata dalla Arinc ad UA93

- tale messaggio "18", il cui campo "flag_31" è settato a "2", è stato inviato da "ROB" (Robert Brittain), e come RGS riporta "/GL DEC" (RGS di Decatur)

Adesso, se andiamo ad incrociare queste informazioni con quelle presenti nei log Arinc presentati da Warren Stutt, possiamo notare che:

FLoc	BEPts	Target Stn	Stn	Org TimeStamp	Reason Code	Block Type
365464105	20010911 14:13:30		IADA6			ULBLK
365550345	20010911 14:13:40		IADA6			ULBLK
365612804	20010911 14:13:50		IADA6			ULBLK
365678382	20010911 14:14:00				311	ICPUL
365678701	20010911 14:14:00				231	ICPUL
367059755	20010911 14:17:39	CMI 00 00		20010911 14:17:00		ULMSG
367059889	20010911 14:17:39				231	ICPUL
367187539	20010911 14:18:03	CMI 00 00		20010911 14:17:00		ULMSG
367187673	20010911 14:18:03				231	ICPUL
367542701	20010911 14:19:04	CMI 00 00		20010911 14:19:00		ULMSG
367542835	20010911 14:19:04				231	ICPUL
368197741	20010911 14:21:06	DEC 00 00		20010911 14:20:00		ULMSG
368197875	20010911 14:21:06				231	ICPUL

Il messaggio UAL "18" ( l'unico con valore "2" al "flag_31") è perfettamente allineato con quello Arinc "FLoc" 368197741, "BEPts" 20010911 14:21:06, ULMSG, "/GL DEC", dispatcher ROB e "Reason Code 231" (Reason code 231 = "no station to", secondo quanto indicato nelle specifiche Arinc 618, come riportato da booNyzarC, vedasi qui )

Ebbene, su ciò a cui fanno riferimento i valori "blank", "1" e "2", si può al momento solo speculare, visto che una tale informazione è di pertinenza direttamente della UAL (essendo i loro log delle comunicazioni ACARS tagliati direttamente sulle loro esigenze e apparecchiature).

Ma, quello che comunque si può e si deve sapere e notare è che:
- i printouts di Ballinger sono quelli che arrivano alla UAL dalla ARINC, in risposta ai messaggi di testo inviati dalle postazioni dei dispatcher (Ballinger) della UAL. Ossia sono log che già sono passati attraverso un'elaborazione fatta da parte della ARINC. [ *vedi nota 01]

- il valore "2" non è funzione diretta nè di "CMD" nè di "AGM"

- i log UAL presentano uno e uno solo messaggio certamente "non recapitato/non inoltrato" ad UA93

- nei log ARINC, sono presenti 5 marcatori impostati a "231 ICPUL" ("no station to")

- sia nei log ARINC sia in quelli UAL, ci sono 3 ULMSG indicanti la RGS GL/CMI
- nei log ARINC, gli ultimi 3 ULMSG indicati con la RGS GL/CMI, sono anche marcati con ICPUL 231 ("no station to")
- nei log UAL gli stessi tre messaggi hanno "flag_31" impostato a valore "1", e RGS GL/CMI

- sia nei log ARINC sia in quelli UAL, cìè un ULMSG indicato con la RGS GL/DEC
- nei log ARINC, l'ultimo ULMSG indicato con la RGS GL/DEC, è anche marcato con ICPUL 231 ("no station to")
- nei log UAL lo stesso ultimo messaggio ha "flag_31" impostato a valore "2", e RGS GL/DEC

Ognuno tragga le proprie conclusioni.


[*Nota 01]
Questo è un dato certo, facilmente comprensibile oltre che dalla diversa formattazione del messaggio (gli asterichi; la mancanza di un secondo campo timestamp; la mancanza del numero progressivo segnato dal counter) anche dalle parole di Steve Ledger ( Director of AQP services- ARINC ):

"The Central Processing System (CPS) time stamp in the second line is the Greenwich mean (universal) time at which the message was electronically processed at the ARINC center in Annapolis, MD, before being sent to a ground station and then transmitted to the aircraft. The time it would take for the message to get from this point to the cockpit of the aircraft would vary, depending on the size of the message, and how much message traffic there was. In rare cases, this could mean that it would take minutes for the final delivery, but typically, for short messages (under 220 characters) like the ones sent to Flights 175 and 93, the delivery time would be within 10 seconds. The message is not stamped with the time it is received in the cockpit".

Leggi l'articolo... | ...Torna alla HOME