free flight - flight management system brite/euram project · this schema shows the function of the...

Free Flight - Flight Management SystemBrite/EuRam project

3FMS DEMONSTRATORAIRBORNE LINK

DESIGN DOCUMENT(AL-DD)

P/N: WP 2.4

Rev: 1C

Date: March 31st, 1999

SXT AS SI ETG NLR RTSN2 DERA

Author’s name C.BAILLYF.BATAILLE

Approvals

3FMS DEMONSTRATOR - Airborne Communications

3FMS PROJECT

TABLE OF CONTENTS

1. PURPOSE AND SCOPE............................................................................................................ 3

2. SYSTEM OVERVIEW .............................................................................................................. 4

3. DESIGN METHOD.................................................................................................................... 5

4. AIRBORNE LINK...................................................................................................................... 6

4.1 FUNCTIONNAL DESCRIPTION.................................................................................................... 74.2 AIRBORNE LINK IMPLEMENTATION IN 3FMS ........................................................................ 104.3 AIRBORNE LINK DESIGN................................................................................................. 11

4.3.1 Data set.............................................................................................................................. 114.3.1.1 Overview ...................................................................................................................... 11

4.3.2 Data Management ............................................................................................................. 114.3.2.1 Error cases.................................................................................................................... 124.3.2.2 Periodic Data Requests ................................................................................................ 134.3.2.3 Simplex Data Requests ................................................................................................ 134.3.2.4 Event Requests ............................................................................................................. 134.3.2.5 Load Requests .............................................................................................................. 154.3.2.6 Cancel Requests ........................................................................................................... 164.3.2.7 Output Messages .......................................................................................................... 174.3.2.8 Overview ...................................................................................................................... 174.3.2.9 Managed Information................................................................................................... 184.3.2.10 SNMP transport service definition ........................................................................... 184.3.2.11 SNMP PDU Definition............................................................................................. 194.3.2.12 Information Transfer ................................................................................................ 19

4.3.3 Decomposition ................................................................................................................... 254.3.3.1 Use cases ...................................................................................................................... 264.3.3.2 Classes description....................................................................................................... 26

4.3.3.2.1 COM Class.............................................................................................................. 264.3.3.2.2 CFIB Class.............................................................................................................. 26

4.3.3.2.2.1CFIB Manager.................................................................................................. 264.3.3.2.2.2CFIB Agent ...................................................................................................... 26

4.3.3.2.3 MIB Class ............................................................................................................... 274.3.3.2.4 FM Class................................................................................................................. 27

5. APPENDICES........................................................................................................................... 28

5.1 ACRONYMS......................................................................................................................... 285.2 REFERENCES ...................................................................................................................... 29


3FMS PROJECT

1. PURPOSE AND SCOPEThis document part of WP2.4 is dedicated to airborne link. This package is defining the architectureof the COM/FM communication and the identification of messages sets and protocols implementationused to exchange. Implementation details will be presented and developped later in the WP3.4“Airborne Link Software Detailed Design”.


3FMS PROJECT

2. SYSTEM OVERVIEW

This schema shows the function of the Airborne Link used on this schema by the ADS-B. The numberupon the arrow indicate the order in which the action takes place.

The Airborne Link is drawn on the right side the synoptic. It is used to ask the FM to retrieve data tobe then sent to the Traffic Simulator.The left part of the drawing is detailled in the COMMDD document.

TrafficSimulator

TrafficSituation ADS-B

AirborneLink

FM

1

2 1 2

340

Figure 1: System Overview


3FMS PROJECT

3. Design MethodThe design method will be based on the OMG standard object-modeling method: UML.This method is relevant to the design because all the communication software will be coded usingC++.


3FMS PROJECT

4. AIRBORNE LINKThe airborne link specifies the generic interface to be used between any avionics exchanging binarymessage oriented data. This interface will be located between the FMS and the COM module.

Note:In the frame of 3FMS there will not be a COM Unit (COM or ATSU), so the Airborne link willbe used only by ADS-B application to obtain or send data to the FMS, nevertheless in thefollowing the COM Module will represent the end of the Airborne Link not connected to theFMS.

Figure 2-Typical Airborne link

This interface provides a mechanism to transfer information between the COM part and the FM, toupload different databases in both avionics. It provides a "client-server" relationship such that boththe COM module and FM can act as both clients (insert or request data) and servers (providerequested data).

COMFMS

Air

born

e li

nkin

terf

ace

Airborne linkinterface


3FMS PROJECT

Functionnal descriptionHence, different functional modules have been identified for the airborne link design.

D ata m an agem en t

D a ta transfe r

L in k

F M S d a tab ase

data

base

_inf

osda

ta_r

eque

st

data_delivery

data

_sen

d data_receive

F M S

D ata m anag em ent

D a ta tran sfer

L in k

data

_req

uest

data_delivery

data

_sen

d data_receive

database_uploading

lin k to A T S U

lin k to F M S

A p p lica tio n s

C O Mgr

ound

_inf

o

air_info

Figure 3-Functionnal description

When required by the FMS, this database can be polled and information can be retrieved from theCOM module. The airborne link is the interface between the two entities which handles with thedatabase exchanges.

The system environnement has two different external items. The FMS database containing all theflight and navigation information is one of those items.On the COM side, applications interface with the communications environment. Those applicationsretrieve messages such as ADS messages, providing data to the COM module. The data contained inthe FMS and in the COM function have to be exchanged via the airborne link interface. The twoavionics will behave in a two-way client-server configuration, and share the information available.


3FMS PROJECT

In order to enable such a process, three different functionnal blocks have been identified:

Data management function:

On the COM side, this module is fed by air-air messages, and by the FMS on the other side.The Data management module monitors the database, that is loading new information and allows todeliver specific data when asked by the FMS.The Data management module can request the peer DM (server) to send a specified list of data once,periodically, or when a defined event occurs in the server. The client can also request for data to bevalidated and loaded into the server. These types of transaction are referred to as "contracts". Theclient can cancel a request (or contract) at any time.Data bases can be uploaded from the COM module to the FMS and vice versa.

Connectionmanagement

Databasemanagement

Messagesformating Transfer

Data Management

ApplicationDatabase/FM

Figure 4-Data management functions

Three different modules can be identified for the Data management design:- The connection management module handles with the connections information. Its role is in the firstplace to initialize the process. It allows to provide connections instructions such as: termination andabort procedures.- The database management allows different kinds of operations: get information from the server, setattributes values in the database, initialize contracts with the server or cancel those contracts.- The messages formating module is the message designer, connection request as well as databasesrequests are encapsulated in proper format and sent to the Transfer module.


3FMS PROJECT

Transfer:When proper information has been extracted from the database, the data have to be formatted forcommunications purposes. The transfer module handles with communication standards dedicated todatabase exchanges between the FMS and the COM module.

T ra n s fe rm a n a g e m e n t

M e ss a g e sfo rm a tin g

Dat

a

man

agem

ent L in k

T ra n s fe r t M o d u le

Figure 5-Transfer functions

The transfer module’s goal is to allow messages to be forwarded to the link modules.- The transfer management function is dedicated to initialization; registration procedures.- The messages formating module retrieves data coming from the data management module andformats those data as expected in the link module. It also gathers messages from the transfermanagement module and formats those transfer management messages.


3FMS PROJECT

Link:The Link module is the interface between the two avionics. It allows to carry the informationformatted by the transfer module.

L in k S ta tu s(M IB )

M essage stra nsm issio n/e m iss ion

Tra

nsfe

rD

estination

L in k M o d u le

Figure 6-Link functions

- The management information base is assumed to contain a parameter (Link Status) which indicatesthe health of the link module and its services. It can communicate to the transfer module to indicatethe success or failure of the previous data transfer.- The messages transmission/emission function allows to send given data to the destination peer linkmodule. This module feeds the management information base with status information about datatransfer.

4.1 Airborne link implementation in 3FMSThose functionnal aspects can be developped on telecommunications layers basis. The Datamanagement module can then be implemented as an application layer, relying on a transport layer.This whole system has to be used on an underlying link layer. For real implementation, the transportand above layers will be designed under a TCP/IP architecture. This stack-like protocol will enable tosimulate a real transport effective service.More than a simulation, it is important to note that TCP/IP is becoming more and more important inavionics communication, and is under study for real airborne implementation. 3FMS is then theproper place to get experience on this subject.

Moreover, SNMP, which actually is a network manager, will be implemented for networkmanagement as well as data management. This will be an adapted version of SNMP, developped tosupport different patterns of data management in its Management Information Base (MIB).


3FMS PROJECT

S im u la ted a irb o r n e c o m m u n ic a t io n S ta ck

(A S E )

A P P L I

(F M )

T C P /U D P

IP

L L C 1

IS O 8 8 0 2 -2

d ev e lop e d fo r 3 F M S

E th e rne t

IE E E 8 0 2 .3

S N M P

Figure 7-Airborne communications protocols

4.2 AIRBORNE LINK DESIGNThe airborne link shall be implemented according to detailed specifications. As it is dedicated to dataexchanges between the FM and the COM workstations, it is important to quantify the amount of databound to be transmitted, as well as the data contents.

4.2.1 Data set

4.2.1.1 OverviewThe data set exchanged between the two entities consists of four types of messages:

• Full request messages,• Partial request messages,• Output messages,• Status messages.

The Protocol Data Units are encoded according to ISO Abstract Syntax Notation One (ASN.1).Only a small part of all defined PDUs in Arinc 656 will be implemented for the 3FMS demonstratordepending on the need of both side of the airborne link.

4.2.2 Data ManagementAs said in the previous chapters, the data management will be implemented using an SNMPapplication. This application is defined below and described in the goal to provide a proper datamanagement between the FMS and the COM. The SNMP application relies on a underlyingTCP/UDP and IP to send and receive Data Management Service data units. Details of the underlyingdata link and physical layers are hidden from the SNMP application.Once initialized, the server SNMP entity is always in the information transfer state, so that it mayaccept incoming PDUs from its peer SNMP client.


3FMS PROJECT

The SNMP information transfer mode consists of a full or partial "Request message" responded to byeither an "Output message" or a "Status message" in either one-to-one, one-to-many periodic or one-to-many aperiodic patterns of communication.The server’s output data may not have a one-to-one correspondence with the client’s request data. Forexample, the client may wish to ask the server "When will you reach FL320?" via output elementExpected Time at Altitude. This request Message contains the altitude. When the server responds,however, the Output Message will contain a time (not an altitude).

The client can request the server to send a specified list of data once, periodically, or when a definedevent occurs in the server. The client can also request for data to be validated and loaded into theserver. These types of transactions are referred to as "contracts". The client can cancel a request (orcontract) at any time. All these types of messages are initiated via a "Request Message".

c lie n t se rve r

req u e st

res p o n s e

c lie n t s e rve r

u n s o llic ite dres p o n s e

c lie n t se rve rreq u e st

re s p o n s e

re s p o n s e

re s p o n s e

c lie n t se rve rre q u e s t

re s p o n s eres p o n s e

re s p o n s e

O n e-to -O n e

O n e-to -M an y P e rio d ic O n e-to -M a n y A p erio d ic

U n so llic ited resp o n se(T rap )

Figure 8-SNMP communication patterns

4.2.2.1 Error cases

When the server cannot support another contract due to limited resources, the server responds with an"notready" Status message, and no further processing is performed on the Request Message.

When the Request Message is in format not supported by the server, the server responds with an"unabletodecode" Status Message, and no further processing is performed on the Request Messages.

When the Request Message does not follow the rules for PDU parameter correlation, for instance, theserver responds with an "unexpecteddata" Status Message, and no further processing is performed onthe Request Message.


3FMS PROJECT

When the Request Message contains an action, trigger, reqelem, or inputelem that the server does notrecognize; or the server is unable to decode the message for any other reason, the server responds withan "unabletodecode" Status Message, and no further processing is performed on the Request Message.

When the Request Message contains an action, trigger, reqelem, or inputelem that the serverrecognizes but does not support; or the server cannot meet the rate contained in the Seconds parameterof a Periodic Data Request, the server responds with an "unabletocomply" Status Message, and nofurther processing is performed on the Request Message.

4.2.2.2 Periodic Data RequestsWhen the client needs a set of data periodically from the server, it sends a request Message to theserver with the message fields set to the following values:

• Action = "requestdata",• Trigger = "periodic" with "Seconds" data,• Reqelem-seqOf = <sequence of elements to be output>

The server immediately sends the data to the client via an Output Message. The server continues to

periodically send the Output Message, at the rate contained in the Seconds parameter. The periodiccontract remains open until:

• The client cancels the contract,• The client replaces the contract,• The client disconnects the connection the contract is on,• The server receives a "reset" Status Message,• Or the server experiences a reset.

4.2.2.3 Simplex Data RequestsWhen the client needs a set of data only once from the server, it sends a request Message to the serverwith the message fields set to the following values:

• Action = "requestdata",• Trigger = "immediate",• Reqelem-seqOf = <sequence of elements to be output>

The server immediately sends the data to the client via an Output Message. After the Output Messageis sent, the contract is considered "closed".

4.2.2.4 Event RequestsWhen the client would like to know when a specified event occurs in the server, or would like a set ofdata when the event happens, it sends a Request Message to the server with the message fields set tothe following values (example is for "waypointchange", but could be for any event):

• Action = "requestdata",• Trigger = "waypointchange" and Waypointchange data,• Reqelem-seqOf = <sequence of elements to be output>

The server immediately sends an "abletocomply" Status Message to the client. When the event occurs in the server, the server responds based upon whether the Reqelem-seqOfparameter was contained in the Event Request Message.


3FMS PROJECT

When the reqelem-seqOf parameter was contained in the Event Request Message, the server transmitsan Output Message containing the requested elements. When the reqelem-seqOf parameter was not contained in the Event request Message, the servertransmits an "eventoccured" StatusMessage. With the exception of the "continuous" waypoint change event, once the event is triggered and theOutput Message or Status Message is passed to the client, the contract is considered "closed". The continuous waypoint change event contract remains open until:

• The client cancels the contract,• The client replaces the contract,• The client disconnects the connection the contract is on,• The server receives a "reset" Status Message,• Or the server experiences a reset.

All servers are expected to provide a trigger event defined as follows:

(The events listed below are typically available when a FMS is acting as a server, in 3FMSdemonstrator scope only useful ones will be implemented)

AT TIME:When the server’s system time matches the time specified in the trigger parameter.

AT POSITION:When the aircraft position matches the position specified in the rigger parameter, within .01

degrees.

AT ALTITUDE:When the aircraft altitude matches the altitude specified in the trigger parameter.

AT SPEED:When the aircraft speed matches the speeds specified in the trigger parameter.

ANP RNP:When the navigator’s ANP exceeds the aircraft’s RNP.

WAYPOINT CHANGE:When the type of waypoint change is" next", when the next waypoint is sequenced.

When the type of waypoint is "specific", and the aircraft sequences the position specified inthe trigger parameter.

When the type of waypoint change is "continuous", and there has been no change in any ofthe defined waypoints (e.g. not floating points) in the flight plan. This includes waypointsequencing, insertion of waypoints, and deletion of waypoints.

CROSS LATITUDE:When the aircraft reaches the latitude boundary specified in the trigger parameter.

CROSS LONGITUDE:When the aircraft reaches the latitude boundary specified in the trigger parameter.


3FMS PROJECT

AT DISTANCE FROM POSITION:When the aircraft reaches the Distance to Go (DTG) to the desired position, within .01degrees, as specified in the trigger parameter.

PASSING ABEAM OF POSITION:When the aircraft passes abeam to the position specified in the trigger parameter.

VERTICAL RATE CHANGE:If the vertical rate specified in the trigger parameter is,positive; and the aircraft’s rate of climexceeds that vertical rate the vertical rate specified in the trigger parameter is negative, whenthe aircraft’s rate of descent exceeds that vertical rate..

DEPART ALTITUDE RANGE:When the aircraft passes through the altitude ceiling or altitude floor specified in the triggerparameter. The server uses pressure altitude for this comparison.

LATERAL DEVIATION CHANGE:When the aircraft’s crosstrack error exceeds the lateral deviation threshold specified in thetrigger parameter.

4.2.2.5 Load RequestsThe client is capable of emulating data entry into the server.With the "validate" action, the server only validates the data to be loaded, and reports the status of thevalidation.The client may request a "load" action, which causes the previously validated data to be loaded.With the "validateandload" action, the server validates and then loads the data only if all data isloadable.The client is only permitted to load data into the server at the time the load request is end. The serverwill not support the loading of data when a future event occurs. (e.g. load wind data when a certainaltitude is reached).

Validate Request:

When the client would like to validate elements prior to loading them into the server, the client sendsa Request Message to the server with the message fields set to the following values:

• Action = "validate",• Inputelem-seqOf = <sequence of elements to load>

When none of the elements can be loaded, the server responds with an "unabletocomply" Status

Message. After the Status Message is sent, the contract is considered " closed". When only some elements can be loaded, the server responds with a "partialload" Status Message.

When all of the elements can be loaded, the server responds with an "abletocomply" StatusMessage.

In these two instances, the contract remains open and the server retains the elements to be loaded

until:

• The client cancels the contract,


3FMS PROJECT

• The client replaces the contract,• The client disconnects the connection the contract is on,• The client sends a Request Message with the "load" action and no dataelem-seqOf

parameter,• The server receives a "reset" Status" Message, or• Or the server experiences a reset.

Validate and Load Request: When the client wants to validate elements prior to loading them into the server and only have theelements loaded if all elements can be loaded, the client sends a Request Message to the server withthe message fields set to the following values:

• Action = "validateandload",• Inputelem-seqOf = <sequence of elements to load>

When none of the elements can be loaded, the server responds with an "unabletocomply" Status

Message. After the Status Message is sent, the contract is considered " closed". When only some elements can be loaded, the server responds with a "partialload" Status Message.

When all of the elements can be loaded, the server responds with an "abletocomply" StatusMessage.

In these two instances, the contract remains open and the server retains the elements to be loaded

until:

• The client cancels the contract,• The client replaces the contract,• The client disconnects the connection the contract is on,• The client sends a Request Message with the "load" action and no dataelem-seqOf

parameter,• The server receives a "reset" Status" Message, or• Or the server experiences a reset.

4.2.2.6 Cancel RequestsWhen the client no longer requires a contract to be in effect, the client sends a Request Message to theserver with the message fields set to the following values:

• Action = "cancelrequest",• Trigger = "periodic" with "Seconds" data,• Reqelem-seqOf = <sequence of elements to be output>

The server immediately sends an "unabletocomply" Status Message. After the Status Message is sent,the contract is considered "closed".


3FMS PROJECT

4.2.2.7 Output MessagesThe server generates an Output Message to the client with the message fields set to the followingvalues:

• Outputelem-seqOf = <sequence of elements containing the requested data>

The Output elements have a one-to-one correspondence between the reqelem and the ouputelem.When there is more than one output element, the output elements are in the same order as the requestelements were in the original Request Message.

If any of the output elements are invalid, the server sends the following in place of the invalidelement(s).

4.3 OverviewSNMP offers a mechanism to transfer information between two or more applications.More generally, the communication between entities can be activated thanks to SNMP protocolmessages.SNMP provides a "client-server" relationship such that the COM and FMS can act as both clients(insert or request data) and server (provide requested data).As SNMP is based on connectionless communication protocol, it can support multiple conversationssimultaneously.SNMP can support either or both client and server role. The application which communicate with oneanother using the SNMP are termed SNMP application entities in SNMP terminology, a server iscalled an agent and a client is called a manager.This section covers the application data transmitted from both the server to the client and from theclient to the server.

Three types of access to managed information are provided by the protocol:

• First type: "request-response" interaction, in which a SNMP entity acting as the client, sendsa request to the server SNMP entity. The latter then responds to the request. This type isused to retrieve or modify managed information associated to the server device.

• Second type is a " request-notification " interaction, in which an SNMP entity acting in a

manager role, sends a request to an SNMP entity , also playing the role of a manager. Thelatter notifies the other with the managed information state or value.

• Third type: unconfirmed interaction, in which an SNMP entity, acting in a server role, sends

an unsolicited message, termed a trap, to an SNMP entity acting as a client, and no responseis communicated in return. This third type is used to notify of an exceptional situation,which has resulted in changes to managed information associated with the server device.


3FMS PROJECT

g e t-re q u e s tg e t-re s p o n se

g e t-n e x t-re q u e s tg e t-re s p o n se

se t-re q u e s tg e t-re s p o n se

tra p

S N M P a g e n t (S e rv e r)S N M P m a n a g e r (C lie n t)

p o rt U D P 1 6 1

p o rt U D P 1 6 2

p o rt U D P 1 6 1

p o rt U D P 1 6 1

G e t-b u lk -re q u e s tg e t-re s p o n se

Figure 9-SNMP operations

Operations are generated by the client, except from the InformRequest, and the Trap, which areserver-generated.SNMP also provides interrogations messages, such as: GetRequest, GetNextRequest,GetBulkRequest, and one load operation: SetRequest.

These set of operations allow a total interaction between a client and a server to manage differentkinds of objects.

4.3.1 Managed InformationManaged information or variable, refers to an instance of a non-aggregate object type.Variables are viewed as a collection of managed objects, residing in a virtual information store,termed the Management Information Base (MIB). Collections of related objects are defined in MIBmodules. These modules are written using a subset of OSI’s Abstract Syntax Notation One (ASN.1),termed the Structure of Management Information (SMI).

4.3.2 SNMP transport service definitionSNMP messages exchanges require only an unreliable datagram service, with every message beingentirely and independently contained in a single transport datagram. This choice is consistent with thegoal of minimizing complexity of the server, the exchange of SNMP messages requires only anunreliable datagram service.

In fact, SNMP relies on the underlying UDP/IP protocols to send and receive Protocol Data Unit(PDU). The User Datagram Protocol offers users a connectionless unreliable protocol and is similar tothe ISO Connectionless Transport Protocol (CLTP).

The User Datagram Protocol offers only a minimum transport service and gives application directaccess to the datagram service of the IP layer.


3FMS PROJECT

4.3.3 SNMP PDU DefinitionThe SNMP message set consists of seven types of messages defined below.

GetRequest-PDU ::=[0] IMPLICIT PDUGetNextRequest-PDU ::=[1] IMPLICIT PDUResponse-PDU ::=[2] IMPLICIT PDUSetRequest-PDU ::=[3] IMPLICIT PDUGetBulkRequest-PDU ::=[4] IMPLICIT PDUInformRequest-PDU ::=[5] IMPLICIT PDUSNMPv2-Trap-PDU ::=[6] IMPLICIT PDU

SNMP PDUs are encoded according to ISO Abstract Syntax Notation One (ASN1). Theimplementation must follow a subset of these rules described in the Structure of ManagementInformation (SMI).The present document will show how each PDU has to be used to comply with data managementconstraints.

Message ::=SEQUENCE {version -- version-INTEGER {version-1(0)

},

community -- community nameOCTET STRING,

data -- e.g., PDUs if trivialANY -- authentication is being used}

4.3.4 Information TransferBoth SNMP client and server entities are always in the information transfer state, so that it mayaccept any incoming PDU from any peer client.

4.3.4.1 Common Constructs:

-- request/response informationRequestID ::= INTEGERErrorStatus ::= INTEGER {

noError(0),tooBig(1),noSuchName(2),badValue(3),readOnly(4)genErr(5)}

ErrorIndex ::= INTEGER-- variable bindings


3FMS PROJECT

VarBind ::= SEQUENCE {nameObjectName,valueObjectSyntax}

VarBindList ::=SEQUENCE OF VarBind

RequestIDs are used to distinguish among outstanding requests. By the use of the RequestID, anSNMP application entity can correlate incoming responses with outstanding requests. In cases wherean unreliable datagram service is being used, the RequestID also provides a simple means ofidentifying messages duplicated by the network.A non-zero instance of ErrorStatus is used to indicate that an exception occurred while processing arequest. In these cases, ErrorIndex may provide additional information by indicating which variable ina list caused the exception.Variable refers to an instance of a managed object. A variable binding, or VarBind, refers to thepairing of the name of a variable to the variable’s value. A VarBindList is a simple list of variablenames and corresponding values. Some PDUs are concerned only with the name of a variable and notits value (e.g., the GetRequest-PDU). In this case, the value portion of the binding is ignored by theprotocol entity. However, the value portion must still have valid ASN.1 syntax and encoding. It isrecommended that the ASN.1 value NULL be used for the value portion of such bindings.

4.3.4.2 Request Message:The client can request the server to send a specified list of data once, periodically, or when a definedevent occurs in the server.

4.3.4.2.1 Immediate Data Request:When the client needs a set of data immediately, it sends a GetRequest-PDU to the server with themessage fields set to the following value:

GetRequest-PDU ::=[0]IMPLICIT SEQUENCE {request-id

RequestID,error-status -- always 0

ErrorStatus,error-index -- always 0

ErrorIndex,variable-bindings

VarBindList}

Upon receipt of the GetRequest-PDU, the receiving protocol entity responds according to anyapplicable rule in the list below:

1. If, for any object named in the variable-bindings field, the object’s name does not exactly match thename of some object available for get operations in the relevant MIB view, then the receivingentity sends to the originator of the received message the GetResponse-PDU of identical form,


3FMS PROJECT

except that the value of the error-status field is noSuchName, and the value of the error-index fieldis the index of said object name component in the received message.

2. If, for any object named in the variable-bindings field, the object is an aggregate type (as definedin the SMI), then the receiving entity sends to the originator of the received message theGetResponse-PDU of identical form, except that the value of the error-status field is noSuchName,and the value of the error-index field is the index of said object name component in the receivedmessage.

3. If the size of the GetResponse-PDU generated as described below would exceed a local limitation,then the receiving entity sends to the originator of the received message the GetResponse-PDU ofidentical form, except that the value of the error-status field is tooBig, and the value of the error-index field is zero.

4. If, for any object named in the variable-bindings field, the value of the object cannot be retrievedfor reasons not covered by any of the foregoing rules, then the receiving entity sends to theoriginator of the received message the GetResponse-PDU of identical form, except that the valueof the error-status field is genErr and the value of the error-index field is the index of said objectname component in the received message.

If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of thereceived message the GetResponse-PDU such that, for each object named in the variable-bindingsfield of the received message, the corresponding component of the GetResponse-PDU represents thename and value of that variable. The value of the error- status field of the GetResponse- PDU isnoError and the value of the error-index field is zero. The value of the request-id field of theGetResponse-PDU is that of the received message.

For example if the COM module needs the FM’s PDBpartnumber, it will send a GetRequest-PDUspecifying that the object it wants to get back is the value of the PDBpartnumber.

The server will answer to such a question thanks to a GetResponse-PDU.The form of the GetResponse-PDU is identical to that of the GetRequest-PDU except for theindication of the PDU type. In the ASN.1 language:

GetResponse-PDU ::=[2]IMPLICIT SEQUENCE {

request-idRequestID,

error-statusErrorStatus,

error-indexErrorIndex,

variable-bindingsVarBindList

}

The GetResponse-PDU is generated by a protocol entity only upon receipt of the GetRequest-PDU,GetNextRequest-PDU, or SetRequest-PDU, as described latter in this document.

Upon receipt of the GetResponse-PDU, the receiving protocol entity presents its content to its SNMPapplication entity.


3FMS PROJECT

4.3.4.2.2 Conditional data requestAs the MIB specified for our application will have a trigger field specified for each object, it willallow us to design all Request Messages with a trigger.

This request will consist in setting the trigger to the corresponding object:The SetRequest-PDU syntax is identical to that of the GetRequest-PDU except for the indication ofthe PDU type.In the ASN.1 language:

SetRequest-PDU ::=[3]IMPLICIT SEQUENCE {

request-idRequestID,

error-status -- always 0ErrorStatus,

error-index -- always 0ErrorIndex,

variable-bindingsVarBindList

}

The SetRequest-PDU is generated by a protocol entity only at the request of its SNMP applicationentity.

Upon receipt of the SetRequest-PDU, the receiving entity responds according to any applicable rule inthe list below:

1. If, for any object named in the variable-bindings field, the object is not available for set operationsin the relevant MIB view, then the receiving entity sends to the originator of the received messagethe GetResponse-PDU of identical form, except that the value of the error-status field isnoSuchName, and the value of the error-index field is the index of said object name component inthe received message.

2. If, for any object named in the variable-bindings field, the contents of the value field does not,

according to the ASN.1 language, manifest a type, length, and value that is consistent with thatrequired for the variable, then the receiving entity sends to the originator of the received messagethe GetResponse-PDU of identical form, except that the value of the error-status field is badValue,and the value of the error-index field is the index of said object name in the received message.

3. If the size of the Get Response type message generated as described below would exceed a local

limitation, then the receiving entity sends to the originator of the received message theGetResponse-PDU of identical form, except that the value of the error-status field is tooBig, andthe value of the error-index field is zero.

4. If, for any object named in the variable-bindings field, the value of the named object cannot be

altered for reasons not covered by any of the foregoing rules, then the receiving entity sends to theoriginator of the received message the GetResponse-PDU of identical form, except that the valueof the error-status field is genErr and the value of the error-index field is the index of said objectname component in the received message.

If none of the foregoing rules apply, then for each object named in the variable-bindings field of thereceived message, the corresponding value is assigned to the variable. Each variable assignment


3FMS PROJECT

specified by the SetRequest-PDU should be effected as if simultaneously set with respect to all otherassignments specified in the same message.

The receiving entity then sends to the originator of the received message the GetResponse-PDU ofidentical form except that the value of the error-status field of the generated message is noError andthe value of the error-index field is zero.

4.3.4.2.3 On Event RequestWhen a previouly defined event happens (e.g. reach of a certain Flight Level), a Trap-PDU is createdand sent to the application entity.

Trap-PDU ::=[4]IMPLICIT SEQUENCE {

enterprise -- type of object generating-- trap, see sysObjectID in [5]

OBJECT IDENTIFIER,agent-addr -- address of object generating

NetworkAddress, -- trapgeneric-trap -- generic trap typeINTEGER {

coldStart(0),warmStart(1),linkDown(2),linkUp(3),authenticationFailure(4),egpNeighborLoss(5),enterpriseSpecific(6)},

specific-trap -- specific code, present evenINTEGER, -- if generic-trap is not

-- enterpriseSpecifictime-stamp -- time elapsed between the last

TimeTicks, -- (re)initialization of the network-- entity and the generation of the trap

variable-bindings -- "interesting" informationVarBindList

}

Upon receipt of the Trap-PDU, the receiving protocol entity presents its contents to its SNMPapplication entity.

Interpretations of the value of the generic-trap field are:1. The coldStart Trap: A coldStart(0) trap signifies that the sending protocol entity is reinitializing

itself such that the agent’s configuration or the protocol entity implementation may be altered.2. The warmStart Trap: A warmStart(1) trap signifies that the sending protocol entity is reinitializing

itself such that neither the agent configuration nor the protocol entity implementation is altered.3. The linkDown Trap: A linkDown(2) trap signifies that the sending protocol entity recognizes a

failure in one of the communication links represented in the agent’s configuration. The Trap-PDUof type linkDown contains as the first element of its variable-bindings, the name and value of theifIndex instance for the affected interface.


3FMS PROJECT

4. The linkUp Trap: A linkUp(3) trap signifies that the sending protocol entity recognizes that one ofthe communication links represented in the agent’s configuration has come up. The Trap-PDU oftype linkUp contains as the first element of its variable-bindings, the name and value of the ifIndexinstance for the affected interface.

The authenticationFailure Trap: An authenticationFailure(4) trap signifies that the sending protocolentity is the addressee of a protocol message that is not properly authenticated. Whileimplementations of the SNMP must be capable of generating this trap, they must also be capable ofsuppressing the emission of such traps via an implementation-specific mechanism.The egpNeighborLoss Trap: An egpNeighborLoss(5) trap signifies that an EGP neighbor for whomthe sending protocol entity was an EGP peer has been marked down and the peer relationship nolonger obtains. The Trap-PDU of type egpNeighborLoss contains as the first element of its variable-bindings, the name and value of the egpNeighAddr instance for the affected neighbor.The enterpriseSpecific Trap: A enterpriseSpecific(6) trap signifies that the sending protocol entityrecognizes that some enterprise-specific event has occurred. The specific-trap field identifies theparticular trap which occurred.For example, the client may wish to ask the server "Give me the fuel temperature at altitude FL320".It will then send a GetRequest-PDU with the object fueltemperature.trigger =AT_ALTITUDE_FL320.When it will have reach the FL320, it will then send a notification.

4.3.4.3 Data LoadingThe client can also request for data to be loaded into the server.In this case it will use the set message which has been described bellow.This mechanism allow to load any value if it has the authorization of it. Indeed, the MIB whichcontains the reference to all the elements available also contains a field for each element specifying ifthe value is read only or not.


3FMS PROJECT

4.3.5 Software DecompositionIn the 3FMS scope, communication will only be on the direction from COM module to FM whenADS-B application asks data from FM at periodic time interval to be then sent to others aircrafts.

This scenario is drawn below :

Figure 10: Airborne Link Layers

The FM’s Manager Information Base is only updated as shown on this schema for each GetRequest orSetRequest send by the COM module.Considering this, it may be useful to put a protection to limit the number and the rate of request sentto the FM, and use the MIB like a kind of cache (proxy) if the requests come to fast. In this caseinformation store in the MIB has to be valid only for a time to be defined.

The UML Decomposition derives from this schema.

SNMP Manager

UDP

IP

SNMP Agent

UDP

IP

MIBFM

MIBManager

FMCOM

getRespons getRequest getRequest getRespons

CFIB Manager CFIB Agent

MIBCOM

MIBManager


3FMS PROJECT

As seen on the former decomposition, there is two parts, one concerning the COM and oneconcerning the FM, the link between both being an UDP/IP layer.On both end, the COM interface and the FM interface are encapsulated in objects.

4.3.5.1 Use casesThe following part presents the interaction between the three identified objects used to communicaterequest from the COM to the FM.In this scenario the COM is the initiator of the request.

On the other side (beside the FM), we have the interaction:

4.3.5.2 Classes description

4.3.5.2.1 COM ClassThe rule of object from this class is to translate request coming from outside the aircraft into an objectmessage to propagate the request toward the FM.

4.3.5.2.2 CFIB ClassCFIB Class exist under two form, a Manager form and an Agent form, because depending on thedirection of the request each object acts either as a manager either as an agent.The rule of this class is to encapsulate SNMP protocol and provide some extensions to this protocole(eg: Real SNMP doesn’t implements periodic requests as request by the future ARINC656).

4.3.5.2.2.1 CFIB ManagerCFIB Manager object represents the client in a client/server architecture. Its role is to send andreceive requests to/from the CFIB Agent what ever is the transport layer.

4.3.5.2.2.2 CFIB Agent

COM CFIB ManagergetInfo getRequest

getResponserecvInfo

CFIB Agent MIBgetInfo getRequest

getResponserecvInfo

FM InterfacegetInfo

sendInfo

SNMPUDPIP

SNMPUDPIP


3FMS PROJECT

CFIB Agent is the only part which is linked to the device from which data are needed. There is asmuch CFIB Agent as there are devices. In our scope, the only device is the FM.

4.3.5.2.3 MIB ClassThe purpose of object of this class is to provide a mean of proxy (cache) for data coming from thedevice. For example, if a CFIB Manager ask too many times in a short time interval the same valuefrom the FM, the MIB class can provide the information previouly obtained from the FM and stillvalid.

4.3.5.2.4 FM ClassAs for the COM, the purpose of this class is to mask to the user the low level interaction with the FMand also provide loose coupling to help the application being more robust to FM interface changes.


3FMS PROJECT

5. APPENDICES

5.1 ACRONYMS

ADS Automatic Dependant SurveillanceATN Aeronautical Telecommunications NetworkASN.1 Abstract Syntax Notation OneCPDLC Controller Pilote Data Link communicationFIS Flight Information ServicesIP Internet ProtocolMIB Management Information BasePDU Protocol Data UnitSNMP Simple Network Management ProtocolTCP Transmission Control ProtocolUDP User Datagram Protocol


3FMS PROJECT

5.2 REFERENCES

• Transport layer protocol definition :user datagram protocol B. Reynolds Rockwell Collins• RFC-768, Postel, J.B. 1980, "User Datagram Protocol"• RFC-1157, Case, J.D., Ferdor, M.S., Schoffstall, M. L., and Davin, C. 1990 "Simple Network

Management Protocol"• RFC-1213, McCloghrie, K., and Rose, M.T. 1991 "Management Information Base for Network

Management of TCP/IP based Internet: MIB-II"

free flight - flight management system brite/euram project · this schema shows the function of the...

Documents