| Internet-Draft | eXtensible Stateless Eqpt Data Exchange | August 2023 |
| Spencer & Guy | Expires 3 February 2024 | [Page] |
This document presents a binary IP-based protocol to facilitate interoperable communications between avionics equipment. The protocol is UDP-based, stateless, and broadcast. Messages consist of a common header followed by a series of parameters and related attributes. The parameters are always informational, e.g., indicating airspeed is 150 kts, but parameter attributes can be set to indicate intent, e.g., this parameter contains a new user selected value such as an instruction that deploys the landing gear.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 February 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Historically, avionics equipment has used private protocols for device interconnection but the trend is towards open communication leveraging standard hardware. There have been various stages in the evolution of device interconnection from point-to-point analog communication to digital serial protocols, to bus-based solutions and currently IP-based over ethernet.¶
One of the concerns with all of these protocols in this industry is that extensive testing is required, so developing a common protocol and library with its extensive test cases will improve time to market, product quality, and hence lower cost and improved safety.¶
The eXtensible Stateless Equipment Data Exchange, XSEDE, is such an IP-based protocol which provides a common means that facilitates parameter communication between airborne equipment. It is an open protocol which operates using binary-encoded UDP packets sent on a broadcast interface, typically using multicast Ethernet. This approach allows the avionics system to function as a collection of safety-critical microservices with XSEDE at the hub of the entire avionics system. XSEDE can flexibly drive multiple displays and unify all the aircraft's subsystems all at the control of the system integrator.¶
Parameters generally fall into two separate categories: schedule-driven and event-driven. Schedule-driven parameters are those that are sent periodically by the nodes in the system. One example could be the current heading might be reported by a sensors at 10hz. These parameters have a logical expiration time associated with how long they are valid, for example, 250ms. Another example could be the current air temperature or even the current value of the pilot’s desired heading (heading bug.) Event driven parameters are those that occur in response to an external stimuli, e.g., a pilot action on a switch, or an autopilot deciding to change the heading due to reaching an intermediate waypoint. These parameters do not have a logical expiration time associated with how long they are valid.¶
XSEDE is a simple and compact protocol which uses a fast marshaling approach. Parameters may be coalesced, size and time permitting, into a single message to make transport more efficient. The message layout considers quad word alignment issues which can affect performance, especially on ARM-based architectures and pads to maintain efficiency. All messages are broadcast to all receivers so that the protocol is stateless and only the recipient controls whether a parameter will be processed. Since avionics software is subject to intensive testing and validation, XSEDE is designed to be deterministic with the fewest number of formal requirements required for implementation while still permitting the addition of new data formats and parameters through an extensible data model. Such additions can be made either through a future version of the standard or just through localized additionally configured data elements.¶
User and System selected events can exhibit two distinct behaviors: an event that cause an immediate change, e.g., a radio frequency change, and those changes in which a change may take time to be reflected by the system, e.g., selecting a new flap position. In the former case, only one parameter is defined: a request would set the confidence field to USERSEL (or SYSSEL). At the same time, the radio would periodically report with the current setting. In the latter case, these settings are implemented with a pair of parameters, a request (REQ suffix) and a current state Parameter that has no specific suffix. For example, FLAPREQ and FLAPPOS (See Section 3.5) where the first indicates the requested value and the second indicates the actual value.¶
XSEDE is a UDP-based protocol so packet delivery is not guaranteed. However, since XSEDE is typically run on a purpose built network within a specific aircraft, the reliability of the network is still typically very high. Application-level behavior is implemented to ensure critical requests are executed. Since the protocol is stateless, it relies on the requestor to monitor status to ensure an action was taken. For example, if a request to put the landing gear down is made, the requesting application must watch reports of the landing gear position and alert if the request is not satisfied in a timely manner. However, you would be able to see if your request was correctly interpreted by a report, periodic or in response to the event, by the responsible nodes. Notably, the protocol does not contain the concept of incrementing or decrementing a value, just setting a specific value. A user interface which is designed to increment and decrement a value based on a user turning a knob, for example, must track the current value and when an increment is detected, transmit the new, incremented value with the appropriate confidence (most likely USERSEL). If two or more applications are monitoring the same knob from two different computers, they each would be able to redundantly send the same new value without affecting the behavior whether one, two or more such applications were concurrently running.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The eXtensible Stateless Equipment Data Exchange is designed to operate on an airborne platform network. This network is intended to be isolated from the general Internet and comprises instruments, displays, sensors, and actuators performing various functions. XSEDE messages are broadcast to every node on the network. XSEDE message occur in three classes: Maintenance, Operational and Raw.¶
Maintenance and Operational messages consist of a header followed by a series of parameters. Parameters always represent information, a message is purely a collection of parameters. However, the confidence field must be interpreted to determine intent, i.e., the SYSSEL and USERSEL confidence levels MUST be interpreted by responsible nodes to affect changes on the relevant items.¶
XSEDE is stateless. There is no required protocol level response to any command, however, informational responses may be made. For instance, a command to change the radio frequency of a certain radio may generate a application-level response indicating the new radio frequency. All XSEDE messages go to all nodes which simply discard things they don't care about.¶
Raw XSEDE messages consist of a message header which specifies the length of the raw data, followed by that raw data. Raw data is classified as MIL-STD-1553, CANbus, digital samples, or other serial or streaming unframed data.¶
Each node in XSEDE is assigned a source ID. These Source IDs MUST be unique within the XSEDE network. The Source ID and the message number uniquely identify the message and are contained in the message header. Message IDs created by a node MUST be monotonically increasing. A receiving node MUST ignore all duplicate messages. The Source ID and a message number are used to ensure messages are processed in order and only once. Messages MUST be processed in order skipping any missing messages and MUST only be processed once. Senders and Receivers must account for integer overflow in message numbers. There is no retry mechanism at the protocol level; Missing and out-of-order messages SHALL be considered lost and if received out of order, a message MUST be ignored.¶
In addition to the Source ID and Message Number, The XSEDE message header also contains the message class, the Message Operation ID, DO-178 certification level, [DO-178C] the confidence level and the payload length.¶
For best performance, an XSEDE goal is to not send IP datagrams that have to be fragmented. Packets which exceed the MSS size will be fragmented. To achieve this goal XSEDE messages SHOULD be less than the network Maximum Segment Size (MSS) size in length. On a modern Ethernet network, IEEE 802.3 [IEEE8023] specifies a maximum payload size of 1500 bytes. The size of the fixed IPv4 header is 20 bytes [RFC0791] or in IPv6 the fixed header is 40 bytes [RFC2640] UDP headers consume 8 bytes, [RFC0768] the XSEDE header Section 3.1 uses 12 bytes leaving 1460 bytes for parameters or 1440 bytes on an IPv6 network.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
...
: Data :
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
XSEDE messages are formatted as shown in the above diagram and consist of the following fields:¶
This section defines the dictionaries used in the message header. See Section 3.1.¶
Table 1, below, shows the values defined in the msg-class Dictionary. These values identify the message class: raw, maintenance or operational.¶
| Name | Value | Definition |
|---|---|---|
| MAINT | %d2 | Maintenance Message |
| OP | %d3 | Operational Message |
| RAW | %d4 | Access to raw data stream (e.g., RS-232, RS-485, ARINC-429, etc) |
Table 2, below, shows the values defined in the msg-op Dictionary. These options further refine the operational message class.¶
| Name | Value | Definition |
|---|---|---|
| FLIGHTDATA | %d2 | Flight Data Info |
| DEVSTATUS | %d3 | Device Status |
| GDL90 | %d4 | GDL-90 Format Messages without framing, FCS or escape characters. [GLD90] |
Table 3, below, shows the values defined in the msg-flag-cert Dictionary. These choices represent the message and parameter certification level tracking with respect to the [DO-178C] specification. The message value represents the certification value of the transmitter, where the parameter value represents the source data node's certification value.¶
| Name | Value | Definition |
|---|---|---|
| EXPERIMENTAL | %d0 | Experimental |
| LEVEL-E | %d1 | DO-178 Level E |
| LEVEL-D | %d2 | DO-178 Level D |
| LEVEL-C | %d3 | DO-178 Level C |
| LEVEL-B | %d4 | DO-178 Level B |
| LEVEL-A | %d5 | DO-178 Level A |
Table 4, below, shows the values defined in the tcid Dictionary. XSEDE transcoder ID values or NONE if no transcoder.¶
| Name | Value | Definition |
|---|---|---|
| NONE | %d0 | No transcoder ID is required or asserted |
The section defines the elements common to all XSEDE parameters.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
...
: Parameter Data :
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UINT32; This attribute is the composite of the length and a parameter specific identifier.¶
Nodes MUST compare to their known parameters to this value as a whole; that it to say, an Ident with a different length is a different parameter. This same Ident with a different length situation commonly occurs when sending range parameters but it also can happen when parameter definitions are updated.¶
If the combined value does not match a known parameter/length pair, the parameter data length MUST be determined, then padded to a multiple of four, and the parameter MUST be ignored.¶
Table 5, below, shows the values defined in the param-confidence Dictionary. These options represent parameter format confidence levels.¶
| Name | Value | Definition |
|---|---|---|
| USERSEL | %d192 | User selected value at runtime. Note: expire value SHOULD be zero and MUST be ignored by receivers. |
| SYSSEL | %d224 | System selected value at runtime. Note: expire value SHOULD be zero and MUST be ignored by receivers. |
| HIGH | %d100 | Confirmed known value |
| UNANIMOUS | %d50 | Redundant data available and is rationalized |
| RATIONAL | %d40 | Data being rationalized from other data sources with normal sources ignored |
| VOTED | %d30 | Data is redundantly verified from identical instruments |
| SMOOTHED | %d20 | Smoothed/filtered version of raw data |
| RAW / REPORTED | %d10 | Raw or reported unchecked data |
| ESTIMATE | %d5 | Rough estimation |
| USELESS | %d0 | Value is missing or expected invalid and supplied for debugging ONLY |
The msg_flag_cert Dictionary is also used. See Table 3 for its definition.¶
Information provided in messages have a limited usability lifetime or time-to-live. The Expire field is used to indicate how long the associated parameter is valid. It is an eight-bit field that is split into an exponent and mantissa to provide the maximum range and precision within this small space. The upper four bits represent the the mantissa and the lower four bits represent the exponent. If the value of the Expire field is %x00, the value MUST be interpreted to mean "the parameter does not expire," otherwise the expiry time value MUST be determined by the following formula:¶
Expiration (milliseconds) = (16 + M) * 2^E which can be implemented with ( 0x10 | M ) << E¶
This approach give us the range of 17 to 1015880 milliseconds (about 17 minutes) with 0x00 reserved as "No Expiration."¶
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| M | E |
+-+-+-+-+-+-+-+-+
For example, an expiry value of %x13 gives a mantissa of 0001 and an exponent of 0011 yielding a value of (16 + 1) * 2^E ms or 128 milliseconds.¶
Another example, a value of %xF7 which decomposes to a mantissa of 1111 and an exponent of 0111 yielding a value of (16 + 15) * 2^7 ms, or 3968 milliseconds.¶
The minimum value of %x01 which decomposes to a mantissa of 0001 and an exponent of 0000 yielding a value of (16 + 1) * 2^0 ms, or 17 milliseconds.¶
The maximum value of %xFF which decomposes to a mantissa of 1111 and an exponent of 1111 yielding a value of (16 + 15) * 2^15 ms, or 1015808 milliseconds, which is about 17 minutes.¶
A final example, %x00 which is a special case for "No Expiration."¶
The various attributes associated with parameters occur as both simple types, such as Integers and compound structures, such as Waypoints. This section defines the attribute formats that are used in XSEDE.¶
Boolean Format¶
Parameter Identifier: %d1¶
Length: 4¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| bool-value | boolean | Zero for false, 1 for true, all others undefined |
Table 7, below, shows the values defined in the boolean Dictionary. These options represent the nominal boolean values.¶
| Name | Value | Definition |
|---|---|---|
| FALSE | %d0 | False |
| TRUE | %d1 | True |
Unsigned 32-bit Integer Format¶
Parameter Identifier: %d2¶
Length: 4¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| uint-value | uint32 | 32-bit Unsigned Value |
Waypoint on a Flight Plan¶
Parameter Identifier: %d3¶
Length: 80¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| label | 12*12(OCTET) | Name of waypoint |
| lat | int32 | Latitude of waypoint * 10,000,000 |
| lon | int32 | Longitude of waypoint * 10,000,000 |
| lonlen | int32 | Length of degree of longitude for this latitude in meters |
| alt | int32 | Altitude associated with waypoint in 0.1ft |
| minalt | int32 | Logical Minimum for Fix Crossing in 0.1ft |
| maxalt | int32 | Logical Maximum Altitude for Fix Crossing in 0.1ft |
| speed | int32 | Target indicated airspeed |
| magadj | uint32 | Original (VOR) or Current (GPS) Magnetic Deviation in 0.01 degrees of NAVAID |
| inbound | uint16 | Inbound course in 0.01 degrees |
| outbound | uint16 | Outbound course in 0.01 degrees |
| freqkhz | uint32 | Frequency in khz if this is a NAV AID |
| wtype | fms-waypoint | Type of waypoint |
| ctype | fms-container | Type of container |
| flags | fms-flag | Flags for the waypoint / leg |
| cumete | uint32 | Cumulative ETE from active waypoint in 0.01 seconds |
| cumdis | uint32 | Cumulative distance from active waypoint in 0.001 nm |
| container | 16*16(OCTET) | What container is this waypoint a part of (e.g., V431, ILS-18L, etc) |
Table 10, below, shows the values defined in the fms-waypoint Dictionary. These options represent the flight management system waypoint types.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | Unknown or unspecified |
| GS | %x80 | Glideslope component |
| DME | %x40 | DME Component |
| TACAN | %x20 | TACAN Component |
| VOR | %d1 | VOR Component |
| LOC | %d2 | Localizer component |
| NDB | %d3 | NDB component |
| LDA | %d4 | LDA Component |
| SDF | %d5 | SDF Component |
| FIX | %d6 | Generic RNAV Fix |
| ILS | %d7 | Complete ILS system |
| AIRPORT | %d8 | An Airport |
| DIRECTFROM | %d9 | Starting point of a direct to |
| WEATHER | %d10 | Weather reporting station only |
Table 11, below, shows the values defined in the fms-container Dictionary. These options represent the flight management system container types.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | Unspecified or unknown container |
| NONE | %d1 | No container |
| VICTOR | %d2 | VOR Airway |
| JET | %d3 | Jet Airway |
| AMBER | %d4 | Amber Airway |
| BLUE | %d5 | Blue Airway |
| GREEN | %d6 | Green Airway |
| RED | %d7 | Red Airway |
| Q | %d8 | RNAV Q Routes |
| T | %d9 | RNAV T Routes |
| STAR | %d10 | Standard Arrival Procedure |
| DP | %d11 | Standard Departure Procedure |
| APP | %d12 | Instrument Approach |
Table 12, below, shows the values defined in the fms-flag Dictionary. These options represent the flight management system waypoint and leg flags.¶
| Name | Value | Definition |
|---|---|---|
| NONE | %d0 | No flags or leg type known |
| LEGTYPE-VA | %d1 | Heading to Altitude |
| LEGTYPE-VD | %d2 | Heading to DME Distance |
| LEGTYPE-VI | %d3 | Heading to Next Leg Intercept |
| LEGTYPE-VM | %d4 | Heading to Manual Termination |
| LEGTYPE-VR | %d5 | Heading to Radial Termination |
| LEGTYPE-CA | %d6 | Course to an Altitude |
| LEGTYPE-CD | %d7 | Course to a DME Distance |
| LEGTYPE-CI | %d8 | Course to Next Leg Intercept |
| LEGTYPE-CR | %d9 | Course to Radial Termination |
| LEGTYPE-CF | %d10 | Course to a Fix |
| LEGTYPE-TF | %d11 | Tracking Between Two Fixes |
| LEGTYPE-DF | %d12 | Direct to a Fix |
| LEGTYPE-FA | %d13 | Course from a Fix to an Altitude |
| LEGTYPE-FC | %d14 | Course from a Fix to an Along Track Distance |
| LEGTYPE-FD | %d15 | Course from a Fix to a DME Distance |
| LEGTYPE-FM | %d16 | Course from a Fix to a Manual Termination |
| LEGTYPE-AF | %d17 | Constant DMA Arc to a Fix |
| LEGTYPE-HF | %d18 | Hold to a Fix |
| LEGTYPE-HA | %d19 | Hold to an Altitude |
| LEGTYPE-HM | %d20 | Hold to a Manual Termination |
| LEGTYPE-IF | %d21 | Initial Fix |
| LEGTYPE-PI | %d22 | Procedure Turn to Intercept |
| LEGTYPE-RF | %d23 | Radius to a Fix |
| FLYOVER | %x01.00 | If not present, fly by |
| DISC | %x02.00 | If present, Discontinuity before current waypoint |
| ACTIVE | %x04.00 | If present, this is the active waypoint |
| OBS | %x08.00 | If present, waypoint allows OBS to be set |
| FAF | %x10.00 | If present, waypoint is final approach fix or after |
| SUSPEND | %x20.00 | FMS sequencing is suspended at this waypoint |
| LAST | %x40.00 | This waypoint is the last one in the flight plan |
String of characters (may not have NULL termination)¶
Parameter Identifier: %d4¶
Length: length(data) + 0¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| string-value | *(OCTET) | Optionally NUL terminated [ISO88591] String |
CAS Message¶
Parameter Identifier: %d5¶
Length: length(data) + 4¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| level | cas-msglvl | CAS level |
| rsvd | uint8 | Reserved, set to 0 |
| flags | cas-msgflag | CAS related flags |
| label | *(OCTET) | Label for CAS Message |
Table 15, below, shows the values defined in the cas-msglvl Dictionary. These options represent the Message levels for CAS messages and checklist items.¶
| Name | Value | Definition |
|---|---|---|
| CLEAR | %d0 | Clear a previously issued CAS message -- issue from system only |
| DEBUG | %d1 | In-system debugging output only |
| LOG | %d2 | Log to system log, but do not display |
| MAINT | %d3 | Display only for maintenance purposes |
| STATUS | %d4 | Aircraft system status only |
| ADVISORY | %d5 | Advisory, flight crew should be aware, may require later crew response |
| CAUTION | %d6 | Caution, requires immediate flight crew awareness and later response |
| WARNING | %d7 | Warning, requires immediate awareness and response. |
| COMMENT | %d10 | Checklist Comment Associated with Previous Item |
| UNCHKITEM | %d11 | Unchecked Checklist Item |
| CHKITEM | %d12 | Checked Checklist Item |
| CHKBRANCH | %d13 | Checklist Branch Choice |
Table 16, below, shows the values defined in the cas-msgflag Dictionary. These options represent the Additional flags associated with CAS messages.¶
| Name | Value | Definition |
|---|---|---|
| AUTO | %x01 | Item is automatically checked/unchecked |
Signed 32-bit Integer Format¶
Parameter Identifier: %d9¶
Length: 4¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| sint-value | int32 | Signed 32-bit two's complement value |
Bus and Electronic Circuit Breaker Format¶
Parameter Identifier: %d10¶
Length: length(data) + 24¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| state | ecb-state | State of Bus (in terms of ECB) |
| ecbflags | ecb-flag | Flags regarding ECB state |
| involts | int16 | Input Volts on Bus |
| drawamps | int16 | Current draw on bus |
| maxamps | int16 | Max Amps on bus |
| champs | int16 | Caution high amps |
| clamps | int16 | Caution low amps |
| minamps | int16 | Minimum amps on bus (could be -) |
| outvolts | int16 | Output Volts on Bus |
| maxvolts | int16 | Max volts |
| chvolts | int16 | Caution high voltage |
| clvolts | int16 | Caution low voltage |
| minvolts | int16 | Minimum low voltage |
| label | *(OCTET) | Label for BUS Message (System/Item) |
Table 19, below, shows the values defined in the ecb-state Dictionary. These options represent the Electronic circuit breaker status.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | Circuit is in an unknown condition |
| OFF | %d1 | Circuit is turned off |
| ON | %d2 | Circuit is turned on |
| UNDERCUR | %d3 | Circuit is on, <100ma current drawn |
| RESET | %d4 | Request Reset |
| FORWARD | %d5 | ECB is active logical FWD direction |
| REVERSE | %d6 | ECB is active logical REV direction |
| TARGET | %d7 | ECB is set by target, not ON/OFF |
| BRAKELOW | %d8 | ECB is set by target, not ON/OFF |
| SHORTED | %d128 | Short Circuit |
| OVERCUR | %d129 | Overcurrent (but not short circuit) |
| OVERVOL | %d130 | Overvoltage situation |
| DISABLED | %d131 | Disabled by state-fault |
| RUNAWAY | %d132 | Disabled due to runaway (trim/flaps) |
| COLLARED | %d133 | Should not reset in flight |
| JAMMED | %d134 | Mechanical Jam detected |
| PULLED | %d135 | Pulled |
| BACKFLOW | %d136 | Disabled due to reverse current flow |
Table 20, below, shows the values defined in the ecb-flag Dictionary. These options represent the Electronic circuit breaker parameter flags.¶
| Name | Value | Definition |
|---|---|---|
| INPUTVOLTS | %x01 | Input Volts field is valid |
Range description format¶
Parameter Identifier: %d11¶
Length: 24¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| numticks | uint16 | How many valid ticks are in the parameter data |
| units | param-units | Specifier for units for display |
| divisor | int32 | For display purposes, what are logical divisions |
| minval | int32 | Minimum valid value |
| maxval | int32 | Maximum valid value |
| mindisp | int32 | Where display starts (values lower than this are clipped) |
| maxdisp | int32 | Where display stops (values higher tha this are clipped) |
| ticks | starray | Actual tick data representing the scale marks |
Table 22, below, shows the values defined in the param-units Dictionary. These options represent the Units for the encoding and translation of XSEDE parameters.¶
| Name | Value | Definition |
|---|---|---|
| UNSPEC | %x00 | Units not specified |
| INHG | %x00.01 | Use inches of Hg for BARO/MANPRES |
| FT | %x00.02 | Use feet for altitude |
| NM | %x00.03 | Use nautical miles for distance |
| C | %x00.04 | Use celsius for temperature |
| LBFT | %x00.05 | Use pound-feet for torque |
| S | %x00.06 | Use seconds for time |
| A | %x00.07 | Use amps for current |
| V | %x00.08 | Use volts for voltage |
| LB | %x00.09 | Use pounds for weight |
| IN | %x00.0a | Use inches for distance |
| FPM | %x00.0b | Use feet per minute for rate of climb/descent |
| LBPH | %x00.0c | Pounds per Hour for fuel flow |
| DEGPS | %x00.0d | Degrees per second for attitude change |
| DEG | %x00.0e | Degrees for attitude |
| G | %x00.0f | G force for load |
| RGBA | %x00.10 | 8888 RGBA Value |
| KHZ | %x00.11 | Kilohertz for Frequency |
| PCENT | %x00.12 | Percent of Maximum |
| KT | %x00.13 | Knots for Speed |
| NMPLB | %x00.14 | Nautical Miles per Pound |
| KTPS | %x00.15 | Knots per second |
| MACH | %x00.16 | Speed of sound |
| CPM | %x00.17 | Count per minute |
| PPM | %x00.18 | Parts per million |
| LPM | %x00.19 | Liters Per Minute |
| KW | %x00.1a | Kilowatt |
| AH | %x00.1b | Amp Hour |
| HPA | %x80.01 | Use Hecto pascals for BARO |
| M | %x80.02 | Use meters for altitude |
| SM | %x80.03 | Use statute miles for distance |
| F | %x80.04 | Use fahrenheit for temperature |
| NWM | %x80.05 | Use Newton Meters for torque |
| PSI | %x80.06 | Use PSI for MANPRES |
| MPH | %x80.07 | Use miles per hour for speed |
| SMPLB | %x80.08 | Statues Miles per Pound |
| MIN | %x80.09 | Minutes |
| HR | %x80.0a | Hours |
| HP | %x80.0b | Use Horsepower for power |
| KG | %x80.0c | Use kilograms for weight |
| UL | %xff.ff | Unitless |
GPIO summary format¶
Parameter Identifier: %d12¶
Length: 12¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| features | uint32 | 4-bit Feature (XFS_GPIO_FEATURE_*) x 8 |
| outmodes | uint32 | 4-bit Output modes (XFS_GPIO_OUTPUT_*) x 8 |
| inmodes | uint16 | 2-bit Input modes (XFS_GPIO_INPUT_*) x 8 |
| flags | uint16 | Reserved for future use |
APP status format¶
Parameter Identifier: %d13¶
Length: length(data) + 56¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| state | scb-state | State of application* |
| rsvd | uint8 | Reserved bits |
| appflags | uint16 | Flags regarding app |
| period | uint16 | Baseline runtime period (XFS_SCHED_PERIOD_*) |
| avgcpu | uint16 | Average OS CPU time utilization in units per period over last second |
| hwcpu | uint16 | High water OS CPU time utilization in units per period |
| cpulim | uint16 | Limitation of OS CPU time utilization in units per period |
| runtime | uint16 | Max allocated runtime (per period) |
| deadline | uint16 | Deadline for completion (per period) |
| avgruntime | uint16 | Average runtime over last 1s |
| hwruntime | uint16 | High water runtime |
| ivcsw | uint32 | Involuntary context switches |
| aircraftid | 16*16(OCTET) | Aircraft Identifier |
| swrev | 16*16(OCTET) | Software Version Identifier |
| label | *(OCTET) | Name of APP |
Table 25, below, shows the values defined in the scb-state Dictionary. These options represent the Software circuit breaker states.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | State of software is unknown |
| STARTING | %d1 | Application is in startup phase |
| RUNNING | %d2 | Application is running |
| STOPPING | %d3 | Stopping has been requested |
| RESTART | %d4 | Restart Application (PULL + RESET + START) |
| RESET | %d5 | Allow application to be started |
| HUNG | %d6 | Application is running but is no longer responsive |
| DEGRADED | %d127 | Application is running in a degraded mode |
| STOPPED | %d128 | Application is stopped |
| STARTFAIL | %d129 | Application failed startup |
| RUNAWAY | %d130 | Application has a runaway loop |
| OVERCPU | %d131 | Application is using excessive CPU while in RUNNING state |
| OVERMEM | %d132 | Application terminated due to memory overrun |
| EXCEPTION | %d133 | Application terminated due to runtime exception |
| ENDED | %d134 | Application ended without error or request |
| ENDERROR | %d135 | Application ended with error condition |
| PULLED | %d136 | Application should not be allowed to run until reset |
| COLLARED | %d137 | Should not reset in flight |
Weight and Balance Range¶
Parameter Identifier: %d14¶
Length: 16¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| flags | uint16 | Flags if any |
| numslices | uint16 | Number of slices specified |
| maxtakeoff | uint32 | Max takeoff weight |
| maxlanding | uint32 | Max landing weight |
| maxzerofuel | uint32 | Max zero fuel weight |
| slices | starray | Slices that form weight and balance envelope |
Aircraft Update Progress¶
Parameter Identifier: %d15¶
Length: length(data) + 56¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| aircraftid | 16*16(OCTET) | Aircraft Identifier |
| progress | uint32 | Progress |
| progflags | msg-cmd-updstat-flag | Progress Flags |
| activity | 32*32(OCTET) | Description of current activity |
| label | *(OCTET) | Name of CPU being updated |
Table 28, below, shows the values defined in the msg-cmd-updstat-flag Dictionary. These options represent the Maintenance mode status update flags.¶
| Name | Value | Definition |
|---|---|---|
| SUCCESS | %x01 | Update is complete and successful |
| ERROR | %x02 | Error during update |
Position with flags to interpret whether servo should be engaged, disengaged or left alone and whether active¶
Parameter Identifier: %d16¶
Length: 8¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| servopos | int32 | undefined |
| servomode | afcs-servo | undefined |
Table 30, below, shows the values defined in the afcs-servo Dictionary. These options represent the Servo engagement flags.¶
| Name | Value | Definition |
|---|---|---|
| ENGAGE | %x80.00.00.00 | If present in engagement request, along with 'ENGAGED' value, set engagement status |
| ENGAGED | %d1 | For requests, retain current engagement state, for status, present if currently engaged |
| DISENGAGED | %d0 | If engaged, disengage and for status, currently disengaged |
Database Information¶
Parameter Identifier: %d17¶
Length: 92¶
Structure:¶
| Item | Type | Description |
|---|---|---|
| crc | uint32 | undefined |
| name | 16*16(OCTET) | Name of database (e.g., com) |
| supplier | 16*16(OCTET) | Who supplied the database |
| region | 16*16(OCTET) | What region is the data valid |
| cycle | 16*16(OCTET) | What cycle |
| valid | 12*12(OCTET) | date at which validity begins YYYY-MM-DD string |
| expires | 12*12(OCTET) | date after which data has data YYYY-MM-DD string |
All parameter attributes values are typed, but some are further constrained to certain ranges. The ranges may limited in both value and for display purposes. The display 'ticks' can define various classifications such as a green, yellow, or red range. Furthermore, ranges can change over time. For instance, good oil pressure for a cold engine may be normally higher than that for a warm engine and a special parameter can be broadcast to indicate a range change. Table 21 defines the RANGE parameter format.¶
Parameters that have a default range have that range described in the next section. The default range will be displayed in tabular format. Many parameters have default and unchangable ranges, while others have daynamic ranges. Parameters that have dynamic ranges use a parameter that only differs in the length portion of the Parameter Data Len & Ident attribute. and having a RANGE attibute as its payload. The receiving node MUST distinguish between the value and the range parameters by examining the length portion of the parameter's attribute. Should a parameter attribute value be outside the permitted range. the value MUST be ignored.¶
In the style of the next section, a generic range parameter is defined below:¶
This section defines the default attribute ranges that are used in XSEDE.¶
This section declares the initial set of XSEDE parameters. Each parameter is defined by a name and a short description. This is followed by the numeric parameter ID. Next, the meanings of the unit and subunit fields are provided, if applicable. and finally the parameter data format and a reference to the appropriate table defining the parameter attribute type.¶
Table 32, below, shows the values defined in the osk-key Dictionary. These options represent the On screen keyboard keys.¶
| Name | Value | Definition |
|---|---|---|
| 0 | %d48 | Character 0 |
| 1 | %d49 | Character 1 |
| 2 | %d50 | Character 2 |
| 3 | %d51 | Character 3 |
| 4 | %d52 | Character 4 |
| 5 | %d53 | Character 5 |
| 6 | %d54 | Character 6 |
| 7 | %d55 | Character 7 |
| 8 | %d56 | Character 8 |
| 9 | %d57 | Character 9 |
| A | %d65 | Character A |
| B | %d66 | Character B |
| C | %d67 | Character C |
| D | %d68 | Character D |
| E | %d69 | Character E |
| F | %d70 | Character F |
| G | %d71 | Character G |
| H | %d72 | Character H |
| I | %d73 | Character I |
| J | %d74 | Character J |
| K | %d75 | Character K |
| L | %d76 | Character L |
| M | %d77 | Character M |
| N | %d78 | Character N |
| O | %d79 | Character O |
| P | %d80 | Character P |
| Q | %d81 | Character Q |
| R | %d82 | Character R |
| S | %d83 | Character S |
| T | %d84 | Character T |
| U | %d85 | Character U |
| V | %d86 | Character V |
| W | %d87 | Character W |
| X | %d88 | Character X |
| Y | %d89 | Character Y |
| Z | %d90 | Character Z |
| PREV | %d60 | Previous position or < |
| NEXT | %d62 | Next position or > |
Table 33, below, shows the values defined in the com-state Dictionary. These options represent the State of communication radio.¶
| Name | Value | Definition |
|---|---|---|
| IDLE | R | Ready to Receive (Idle) |
| RX | r | Active receiving |
| TX | T | Active transmitting |
| STUCK | S | Stuck Mic |
| FAULT | F | Fault |
Table 34, below, shows the values defined in the ics-mode Dictionary. These options represent the State of intercom system.¶
| Name | Value | Definition |
|---|---|---|
| PILOT | P | Pilot Isolate |
| CREW | C | Crew Isolate |
| ALL | A | All |
| FEATUREMASK | %xff.00 | Mask for intercom features |
| POSITIONAL | %x01.00 | Positional dynamic audio |
Table 35, below, shows the values defined in the xpdr-mode Dictionary. These options represent the Transponder mode and flags.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | Unknown |
| MODEMASK | %x7f | Mask for mode |
| STANDBY | O | Standby |
| GND | G | On Ground |
| AIR | A | Air/Altitude Reporting |
| FLAG-IDENT | %x80 | IDENT Active |
Table 36, below, shows the values defined in the nav-flag Dictionary. These options represent the Navigational flag states.¶
Table 37, below, shows the values defined in the nav-gps Dictionary. These options represent the Global positioning system status.¶
Table 38, below, shows the values defined in the afcs-fd-mode Dictionary. These options represent the Vertical, lateral and yaw modes of flight director.¶
| Name | Value | Definition |
|---|---|---|
| VERT-MASK | %xff | Vertical modes mask |
| LAT-MASK | %xff.00 | Lateral modes mask |
| YAW-MASK | %xff.00.00.00 | Yaw modes mask |
| PITCH | %x01 | Activate pitch mode |
| VS | %x02 | Activate vertical speed mode |
| FLC | %x04 | Activate indicated airspeed mode / flight level change |
| PRF | %x08 | Activate angle of attack / performance mode |
| ALT | %x10 | Arm Altitude mode |
| VNAV | %x20 | Arm vertical nav mode |
| GP | %x40 | Arm approach mode vertical portion |
| FLARE | %x80 | Arm flare mode |
| ROLL | %x01.00 | Activate wing leveler mode |
| HDG | %x02.00 | Activate heading mode |
| NAV | %x04.00 | Arm navigation mode |
| APPR | %x08.00 | Arm approach mode |
| YD | %x01.00.00.00 | Fixed Yaw Damper |
| SLIP | %x02.00.00.00 | Activate slip mode (adjustable YD) |
| SLIPAPPR | %x04.00.00.00 | Activate approach slip mode (adjustable YD) |
Table 39, below, shows the values defined in the afcs-ap-mode Dictionary. These options represent the Vertical, lateral and yaw modes of autopilot and throttle.¶
| Name | Value | Definition |
|---|---|---|
| VERT-MASK | %xff | Vertical modes mask |
| LAT-MASK | %xff.00 | Lateral modes mask |
| THROT-MASK | %xff.00.00 | Throttle modes mask |
| YAW-MASK | %xff.00.00.00 | Yaw modes mask |
| PITCH | %x01 | Pitch mode |
| EPPITCH | %x02 | Pitch mode only for envelope protection |
| ROLL | %x01.00 | Roll mode |
| EPROLL | %x02.00 | Roll mode only for envelope protection |
| SPD | %x01.00.00 | Activate autothrottle speed tracking |
| EPSPD | %x02.00.00 | Autothrottle only for envelope protection (SPD mode) |
| AOA | %x04.00.00 | Activate autothrottle AoA tracking |
| EPAOA | %x08.00.00 | Autothrottle only for envelope protection (AOA mode) |
| TOGA | %x10.00.00 | Activate takeoff / go-around throttle |
| EPTOGA | %x20.00.00 | Autothrottle only for envelope protection (TOGA mode) |
| YAW | %x01.00.00.00 | Yaw mode |
| EPYAW | %x02.00.00.00 | Yaw envelope protection |
Table 40, below, shows the values defined in the engstate Dictionary. These options represent the States of engines.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %x00 | Engine Status Unknown |
| OFF | %x01 | Engine is Off |
| DRYMOTOR | %x02 | Engine Starting |
| STARTING | %x03 | Engine Starting |
| RUNNING | %x04 | Engine Running Normally |
| FLAMEOUT | %x05 | Engine Flamed Out / Failure |
| SHUTDOWN | %x06 | Engine Shutting Down |
| SHUTOFF | %x07 | Engine Shut Off |
| MODE-MASK | %xff | Mask for Engine State |
| FLAG-IGNITION | %x01.00 | Ignition On |
| FLAG-FUEL | %x02.00 | Fuel Shutoff Open |
| FLAG-STARTER | %x04.00 | Starter On |
| FLAG-GENERATOR | %x08.00 | Generator On |
| FLAG-BLEED | %x10.00 | Bleed Air On |
| FLAG-FIRE | %x01.00.00 | Fire Present |
| FLAG-EXTINGUISH | %x02.00.00 | Extinguisher Dispensed |
Table 41, below, shows the values defined in the icing-flag Dictionary. These options represent the Status of ice detection, anti-ice and deicing systems.¶
| Name | Value | Definition |
|---|---|---|
| ENGINE | %x01 | Engine Deicing/Anticing On |
| AIRFRAME | %x02 | Airframe Deicing/Anticing On |
| INSEP | %x04 | Inertial Separator Activated |
| PITOT | %x08 | Pitot/Static Heat Activated |
| PROPHEAT | %x10 | Propeller Heat Activated |
| WINDHEAT | %x20 | Windshield Heat Activated |
| CARBHEAT | %x40 | Carb Heat Activated |
| CARBICEDET | %x40.00 | Carb Icing Detected |
| ICEDET | %x80.00 | Icing Detected |
| ENGINE-FAIL | %x01.00.00 | Engine Deicing/Anticing Failed |
| AIRFRAME-FAIL | %x02.00.00 | Airframe Deicing/Anticing Failed |
| INSEP-FAIL | %x04.00.00 | Inertial Separator Failed |
| PITOT-FAIL | %x08.00.00 | Pitot/Static Heat Failed |
| PROPHEAT-FAIL | %x10.00.00 | Propeller Heat Failed |
| WINDHEAT-FAIL | %x20.00.00 | Windshield Heat Failed |
| CARBHEAT-FAIL | %x40.00.00 | Carb Heat Failed |
| CARBICEDET-FAIL | %x40.00.00.00 | Carb Icing Detection Failed |
| ICEDET-FAIL | %x80.00.00.00 | Icing Detection Failed |
Table 42, below, shows the values defined in the ldggear Dictionary. These options represent the Status of retractable landing gear.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %x00.00 | Gear Status Unknown |
| DOWN | %x00.01 | Landing Gear Down |
| UP | %x80.00 | Landing Gear Up |
| FLAG-FAILED | %x01.00.00 | Landing Gear System is Failed |
Table 43, below, shows the values defined in the station-flag Dictionary. These options represent the Weight and balance station types.¶
| Name | Value | Definition |
|---|---|---|
| FUEL | %x01 | This station is a fuel tank. Its weight will be in XFS_PARAM_FUELLEVL |
| HULL | %x02 | This station corresponds to the basic empty aircraft |
| FIXED | %x04 | This station's weight is not adjustable |
| PASSENGER | %x08 | This station corresponds to a passenger location |
| BAGGAGE | %x10 | This station corresponds to a baggage location |
Table 44, below, shows the values defined in the flight-state Dictionary. These options represent the Status of aircraft within flight profile.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %d0 | The state of the aircraft is not known |
| OFF | %d1 | The aircraft is completely powered down |
| HIBERNATE | %d2 | Minimal aircraft systems online not visible to the pilot |
| PREFLIGHT | %d3 | Minimal aircraft systems for pilot interaction online |
| ENGINE-START | %d4 | Engine(s) are preparing to start or are starting |
| PRETAXI | %d5 | Engine(s) are started, awaiting pre-taxi items |
| TAXI | %d6 | Aircraft is ready or in process of taxiing |
| RUNUP | %d7 | Aircraft is ready for, or in process of performing runup |
| READY | %d8 | Aircraft is ready for and positioned just short of takeoff |
| TAKEOFF | %d9 | Aircraft is in process of performing takeoff |
| AFTER-TAKEOFF | %d10 | Aircraft is airborne immediately but not yet configured for normal climb |
| DEPARTURE | %d11 | Aircraft is on a standard instrument departure |
| CLIMB | %d12 | Aircraft is climbing but not on an instrument departure |
| CRUISE | %d13 | Aircraft is at final cruise |
| DESCENT | %d14 | Aircraft is descending not on a standard arrival |
| ARRIVAL | %d15 | Aircraft is on a standard arrival |
| APPROACH | %d16 | Aircraft is on an instrument approach procedure |
| VISUAL | %d17 | Aircraft is flying a visual traffic pattern |
| MISSED | %d18 | Aircraft is executing a missed approach |
| SHUTDOWN | %d19 | Aircraft engines are shutting down or have shut down |
| SECURE | %d20 | Aircraft systems are shutting down or reconfiguring for preflight |
Table 45, below, shows the values defined in the brake Dictionary. These options represent the Status of wheel brakes.¶
| Name | Value | Definition |
|---|---|---|
| UNKNOWN | %x00.00 | Brake Status Unknown |
| NONE | %x00.01 | Brakes not pressed |
| MAX | %x80.00 | Max Braking |
| PARK | %x01.00.00 | Parking Brake Engaged |
| FLAG-FAILED | %x02.00.00 | Brake System is Failed |
Table 46, below, shows the values defined in the preset Dictionary. These options represent the XSEDE Preset Frequency.¶
| Name | Value | Definition |
|---|---|---|
| MANUAL | %d0 | Manual Tuning (no preset) |
| LAST | %xff.fe | Last selected frequency |
Application software on a node determines when information or raw data need to be sent onto the network. These transmissions are done as messages with raw data and messages with parameters. If subsequent information or raw data having the same message class, ID, and flags occur in a timely fashion, they MAY be coalesced into a single message.¶
For each parameter to be sent, the common header (See Section 3.2) the common data items MUST be populated. In addition, the Ident and Parameter Data MUST be populated with the corresponding data as per Section 3.5. The length in the common header MUST represent the actual length of the data, however, the parameter must be padded to a size that is a multiple of four octets.¶
The message header MUST be populated with the corresponding data as per Section 3.1, the message number MUST be monotonically increasing with an arbitrary initial value, and then the length in the common header MUST be set equal to the sum of the padded parameter length values. Once this assembly process is complete, the message may be transmitted.¶
Body text¶
XSEDE is designed to be used with a broadcast UDP protocol however, there is no requirement to do so. Each endpoint MUST specify a listening address and port number with the default being 224.0.2.69 on port 20234. The actual address and port number are to be chosen by the system designer / installer for their particular needs. [RFC5771] specifies IPv4 Multicast Address Assignments and SHOULD be followed.¶
If the XSEDE message is successfully transmitted, no further action is required.¶
XSEDE messages are received on the address and port that was configured in the prior section. Upon receiving a message, the src id and message number MUST be examined to ensure that this message is neither out of order nor a duplicate: Since lower level network tolopogies may affect the potential for packet delay and retransmission, each node MUST maintain a message look-back window size setting, default 4. Each node MUST also record of the last message number received from a node. If a subsequent message number is received out of order andis within the look back window, the message MUST be discarded. Otherwise, the message is a valid message. This arrangement accounts for both integer overflows and node restarts. Then, if the message is considered valid, each XSEDE node MUST examine each parameter in the XSEDE message to determine if it requires local processing. Local processing is beyond the scope of this document.¶
Since there is no assured message delivery, all parameter interpretations MUST be idempotent to ensure multiple interpretations, or execution results in the same outcome.¶
Since XSEDE operates on a closed network, message signing is not currently supported but may be added in the future.¶
This section illustrates XSEDE features by example. The first example controls the radio.¶
This example sets the radio Set Radio frequency and squelch by broadcasting USERSEL parameters. If a node controlling the radio receives the request, it will respond with a result similar to the one shown afterwards.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 1001 | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | COMFREQKHZ %x00.00.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | USERSEL 192 | %x00 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 122750 or 0x0001 df7e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | COMSQL %x00.00.28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | USERSEL 192 | %x00 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 53 or 0x0000 0035 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After the above parameters affect a change in the radio, or as part of the radio's regularly scheduled parameter broadcast, a message like the following will be transmitted. It has almost all the same values as the original message but would likely include other parameters as well. Only the changed parameters are described.¶
The expire time is chosen at 2-3 times the scheduled broadcast time to ensure a fresh message is received within the valid time period should one be lost.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 1777 | 1255 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | COMFREQKHZ %x00.00.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %xC9 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 122750 or 0x0001 df7e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | COMSQL %x00.00.28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %xC9 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 53 or 0x0000 0035 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Landing Gear changes are different than radio changes in that it may take several seconds to affect a change. In this scenario, we will see a report by the node controlling the landing gear, followed by a parameter showing the user selecting a new value. Next, there will be a series of parameter broadcasts that showing the gear moving into position.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 2222 | 3400 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %x77 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x8000 - up. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %x77 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x8000 - up. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Above we see a periodic message indicating that each of the two landing gear are in an up position. If these were the only two landing gear, an alternative representation would be to send a single parameter with a a unit of zero to indicate all gear is in an up position. The attributes of the message are as follows:¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 1001 | 2001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEARREQ %x00.00.b3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %x00 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x0001, down. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below we see an example message that could have been made by a landing gear button.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 2222 | 3401 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %x77 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x3901, in transit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %x77 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x4121, in transit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above message was sent while the landing gear was in transit. It shows the position values for each gear to be different, but both in transit. The expiry is set to 0x77 and about 2.9 seconds as the sending node intends to send updates at least once per second. The longer time period accounting for potential losses.¶
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| src id | message number |
| 2222 | 3402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg class | message ID | flags |
| 3 = OP | FLIGHTDATA 2 | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcid | len |
| NONE 0 | %x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %xDB | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x0001, down. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unit | SubUnit |
| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Data Len | Ident |
| 4 | LDGGEAR %x00.00.b2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Confidence | Expire | Pflags |
| UINT 2 | RAW / R 10 | %xDB | LEVEL-A 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Parameter Data :
| 0x0001, down. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The mesage above indicates that both landing gear are down (value 0x0001) and the message expiry has increased to 0xDB, or about 59 seconds. Since the gear are now in a static position, the node only intends to send updates every 20 seconds or so following the expire a message at about three times the sending frequency. In practice, to ensure delivery the long expiry should be introduced after at least one prior notification that it reached that state.¶
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶
This protocol is currently designed to be deployed on an isolated private network. As such, message encryption, authenticity, and modification detection are not protocol priorities.¶
Message Interception is not considered a significant threat for XSEDE because there is no private data in the system.¶
Impersonation and Man in the Middle (MITM) are unlikely because normally the network is physically isolated and not routed to other networks. Strategies for signing messages are a future consideration.¶
Due to secure installation and physical isolation, Denial of Service is not a significant concern.¶