• Aucun résultat trouvé

Multi-layer semantic interpretation of Aeronautical information

N/A
N/A
Protected

Academic year: 2021

Partager "Multi-layer semantic interpretation of Aeronautical information"

Copied!
2
0
0

Texte intégral

(1)

ISAE-SUPAERO Conference paper

The 1st International Conference on Cognitive Aircraft

Systems – ICCAS

March 18-19, 2020

https://events.isae-supaero.fr/event/2

Scientific Committee

Mickaël Causse, ISAE-SUPAERO

Caroline Chanel, ISAE-SUPAERO

Jean-Charles Chaudemar, ISAE-SUPAERO

Stéphane Durand, Dassault Aviation

Bruno Patin, Dassault Aviation

Nicolas Devaux, Dassault Aviation

Jean-Louis Gueneau, Dassault Aviation

Claudine Mélan, Université Toulouse Jean-Jaurès

Jean-Paul Imbert, ENAC

Permanent link :

https://doi.org/10.34849/cfsb-t270

Rights / License:

(2)

ICCAS 2020 Multi-layer semantic interpretatio …

Multi-layer semantic interpretation of Aeronautical

information

Content

We present a hybrid architecture for knowledge extraction, in our future digital assistant for pilots in commercial aircraft. We need to automatically decode aeronautical messages known as NO-TAM (Notice to Airmen) and ATIS (Automatic terminal area information service). Those messages include natural language sentences for operationally relevant information, particularly about the availability of runways or taxiways, related limitations or procedures. For example, ILS APCHS IN USE RWY 36R, RNAV RWY 36L APCHS IN USE (“APCHS” stands for approaches, “RWY” stands for runway). Such messages need to be reliably interpreted into a logical form, in order to: push relevant notifications to the pilot, answer his questions, or monitor flight’s compliance with appli-cable constraints. Moreover, in case of pilot incapacitation during a single pilot flight, the aircraft should be able to autonomously divert the flight.

The interpretation starts by “Nested Entity Recognition”. Its aims at recognizing some (possibly not all) semantically relevant entities in the input message (e.g. runway identifiers, aircraft op-erations, restricting conditions) . It is implemented by a recurrent neural network (“annotator”) for NOTAMs, and by grammatical parsers for ATIS. In the longer term, all the messages should be processed by the trained annotator. The grammar used today to annotate the ATIS messages might be used to generate part of the training dataset for the annotator.

The entities detected by this first layer are organized into a graph, which is the input of several interpretation layers. The final graph must be compatible with a target ontology, e.g. regarding the restrictions it introduces. For that, entities or relations must be subtyped (coercion), some new entities have to be inserted in the graph (implicit entities), implicit properties have to be retrieved from the message (ie structured metadata) or operation context, particularly regarding space and time.

The ontology, which is grounded on the fundamental ontology DOLCE, has a double role in the interpretation process: not only it specifies the format of the representations to be produced, but also it is used to determine the understated parts of the input graph.

For example the ontology specifies that a runway closure is a particular type of operational re-striction, that all operational restrictions are time bounded events, and that a runway closure is related to a unique runway, itself defined by its identifier at the airport it belongs to. Technically, it specifies the target format for the knowledge base extracted from the aeronautical messages. With this architecture, not all entities need to be recognized by the annotator. The system can process incomplete constructs and it is robust to some classification or recognition errors from the annotator. Furthermore, it is possible to make light evolutions of the ontology without retraining the annotator. Regarding reliability, the reference to the ontology reinforces the capacity of the system to detect incorrect graphs. Any failure to satisfy all the semantic constraints is a cue that the message is not correct by itself, or that it has not been correctly annotated.

ARNOLD, Alexandre (Airbus)

;

BERNARD, Denys (Airbus S.A.S.)

;

DUPONT, Gérard (Airbus)

Références

Documents relatifs

[r]

[r]

As stated in the introduction, our proposed benchmark algorithm in this pa- per mainly includes four parts: a two-level customization model consisting of ontology profile and

The relationship between the systems engineering design of X and the systems analysis of one of its elements Y b is illustrated in figure 1 above for a system X

While we agree that Dey’s definition is basically correct, it is clear that the reference to what “is considered relevant to the interaction” leaves a lot to be explained. When

Preferred mode of editing (n=13; some projects express multiple preferences) The majority of ontology engineers questioned in our survey preferred an asynchronous approach to

Finally, given the heterogeneity of the ontology libraries (regarding domain, quality, granularity) ontology selection methods will need to consider this issues and compare

If the framework being used does not generate the implementation of the re- sulting ontology from the conceptual representations, after performing all activities at the knowledge