ACARS OVER IP system for non-safety messages

Abstract

The present invention is entitled "ACARS OVER IP SYSTEM FOR NON-SAFETY MESSAGES". The present invention discloses a communication system in an aircraft. The communication system includes a CMU coupled to at least one safety subnet and an AOIP computing device. The AOIP computing device is coupled to at least one non-safety subnet. The AOIP computing device determines whether an ACARS message received from the CMU is an ACARS safety message or an ACARS non-safety message. The AOIP computing device monitors CMU status messages from the CMU. In response to the AOIP computing device receiving an ACARS safety message, the AOIP computing device periodically transmits a second status message, and the second status message indicates that the AOIP computing device is unavailable. In response to determining that at least one safety subnet is available, the AOIP computing device stops periodically transmitting the second status message and transmits a first status message, and the first status message indicates that the AOIP computing device is available.

Description

Background Art

[0001] Today's Aircraft Communications Addressing and Reporting System (ACARS) data link communications are expensive and use ACARS subnets (e.g., Very High Frequency (VHF), Satellite Communications (SATCOM), and / or High Frequency (HF)) via data link service providers such as Aeronautical Radio, Incorporated (ARINC) and Société Internationale de Télécommunications Aéronautiques (SITA).

[0002] Other servers in the aircraft (e.g., ADG300 (Aspen), Wireless Server Unit (WSU), ADG400 (1 Aviation Wireless Server), etc.) can access cheaper, higher bandwidth Internet Protocol (IP) broadband links such as Wi-Fi, cellular and / or broadband SATCOM links.

[0003] However, these other IP broadband servers may not be approved for transmission or reception of ACARS safety messages. Therefore, it may be beneficial to enable transmission of ACARS non-safety messages over IP broadband links that are not approved for transmission of ACARS safety messages. Summary of the invention

[0004] The present invention discloses a communication system in an aircraft. The communication system includes a CMU coupled to at least one secure subnet and an AOIP computing device. The AOIP computing device is coupled to at least one non-secure subnet. The AOIP computing device determines whether an ACARS message received from the CMU is an ACARS secure message or an ACARS non-secure message. The AOIP computing device monitors CMU status messages from the CMU. In response to the AOIP computing device receiving an ACARS secure message, the AOIP computing device periodically transmits a second status message, and the second status message indicates that the AOIP computing device is unavailable. In response to determining that at least one secure subnet is available, the AOIP computing device stops periodically transmitting the second status message and transmits a first status message, and the first status message indicates that the AOIP computing device is available. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Embodiments of the present invention may be more readily understood, and further advantages and uses thereof become more apparent, when consideration is given to the description of the preferred embodiments and the following drawings, in which:

[0006] Figure 1 is a block diagram illustrating an exemplary ACARS Over IP system for non-safety messages;

[0007] Figure 2 is a block diagram illustrating an exemplary AOIP computing device communicatively coupled to an exemplary CMU;

[0008] Figure 3 is a block diagram illustrating state transitions of an AOIP computing device;

[0009] Figure 4 is a flow chart illustrating an exemplary computerized method for transmitting an ACARS non-safety message using an AOIP computing device;

[0010] Figure 5 is a flow chart illustrating an exemplary computerized method for transmitting an ACARS non-safety message using an AOIP computing device; and

[0011] Figure 6 is a block diagram illustrating an example of an electronic device that may be used in some configurations of the present disclosure. DETAILED DESCRIPTION

[0012] In the following detailed description, reference is made to the accompanying drawings which form a part thereof and which illustrate by way of specific illustrative embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is understood that other embodiments may be utilized and logical, mechanical, and electrical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description should not be considered in a limiting sense.

[0013] As described above, some aircraft servers may have access to IP broadband links, such as Wi-Fi, cellular, and / or broadband SATCOM links (in addition to VHF, HF, and SATCOM data links approved for transmission of ACARS safety messages). These other IP broadband servers may interact with the communication management unit (CMU) on the aircraft to transmit and receive ACARS messages via those IP broadband subnet links.

[0014] A peer server on the ground can act as a peer of the CMU and provide access to ACARS messages to and from operators (e.g., ground or onboard service providers, airlines, etc.). These ACARS Over IP (AOIP) communications can use cheaper, higher bandwidth links and bypass high-cost data link service providers (DSPs), allowing the peer server on the ground to work like a DSP. This communication path may not be approved for transmitting ACARS safety messages and therefore may not be connected to air traffic control or air navigation service providers (ANSPs) on the ground. Instead, AOIP traffic can be transmitted to and from airline operators and / or business and general aviation (BGA) operators (such as Honeywell GoDirect), for example, via an ARINC A20 interface.

[0015] In one possible configuration, a CMU may connect to an AOIP-enabled device (e.g., a server) that supports only non-secure messages via the HF radio port (or via the SATCOM radio port if the VHF subnet is the only secure subnet accessible to the CMU). From the CMU's perspective, the AOIP server may appear to be an HF radio (or SATCOM radio) that supports ACARS secure messages. However, in such a configuration, the CMU may need to be updated to prevent non-secure messages from being routed over the "fake" HF radio subnet interface.

[0016] Many CMUs are connected only to a communication subnet that supports both ACARS safety messages and ACARS non-safety messages. Most CMUs do not have logic to prevent ACARS safety messages from being transmitted over a "non-safety only" (i.e., air operator communications (AOC) only) subnet, such as a server (e.g., ADG300) solution that supports AOIP.

[0017] In order to utilize IP broadband links to transport ACARS non-safety messages, any solution should be compatible with the various CMUs and Communication Management Functions (CMFs) deployed today. Some of these CMUs and CMFs and equipment are old and unlikely to be updated.

[0018] Therefore, the problem addressed herein is how to connect an AOIP-enabled server to a CMU 106 (e.g., via an HF or SATCOM ARINC-429 (A429) port) without causing security issues. Furthermore, any solution should be implemented without having to update CMU software (e.g., except for configuration updates of the Aircraft Personalization Module (APM) or loadable AOC configuration database) or recertify the AOIP-enabled server (e.g., ADG300) to RTCA DO-178B Level D or higher (i.e., maintain Level E), which is expensive and time consuming.

[0019] Another challenge is to ensure that the AOIP system does not interfere with the existing safety message delivery process. For example, if a safety message is transmitted via a server that supports AOIP, the AOIP system may not be able to deliver the message because the AOIP system is not connected to ATC or ANSP, and there may be no mechanism to reject the message. Even if there is a discard mechanism, the message may not be declared as undelivered (e.g., with a "NO COMM" alarm) for a long time (e.g., 10 minutes to 12 minutes), and then the safety message can be delivered to another communication subnet (assuming it is available again). In addition, if it confirms the message, the ATC application will indicate that the message has been delivered when the message is not delivered, which may mislead the pilot or application to have received the message. During the 10-minute to 12-minute time period, ACARS can transmit one message per subnet at a time, and the priority of the message can be higher than that of non-safety messages. Therefore, when the subnet where the safety message is approved is unavailable, and the latest message is a safety message, the AOIP server described herein can prevent the transmission of non-safety messages.

[0020] Figure 1 is a block diagram illustrating an exemplary ACARS Over IP system 100 for non-safety messages. The system 100 may include a vehicle 102 in communication with one or more data link service providers (DSPs) 116 and / or one or more peer servers 120 on the ground 101 .

[0021] For teaching purposes, the vehicle 102 may be described herein as an aircraft, such as an airplane, a helicopter, etc. However, it should be understood that the vehicle 102 may be any vehicle 102 that travels via land, air, space, and / or sea, such as a car, a train, a ship, a submarine, an aerial drone, a spacecraft, etc.

[0022] As used herein, the term "uplink" refers to communications transmitted from the ground 101 (e.g., data link service provider 116 or peer server 120) to the vehicle 102. The term "downlink" refers to communications transmitted from the vehicle 102 to the ground 101 (e.g., to the data link service provider 116 or peer server 120).

[0023] The vehicle 102 may include avionics, including but not limited to an AOIP computing device 104, a communication management unit (CMU) 106, and a router 108. In addition, the vehicle 102 may include one or more communication interfaces for transmitting downlink messages to the ground 101 and receiving uplink messages from the ground 101. The vehicle 102 may also be connected to an ACARS terminal system to send / receive ACARS messages with an ACARS device (not shown). ACARS may transmit non-safety information or safety and non-safety messages.

[0024] The CMU 106 in the vehicle 102 can act as a router for transmitting data link messages to and receiving data link messages from the ground 101. The CMU 106 can be communicatively coupled to the AOIP computing device 104 and other avionics equipment. The data link messages transmitted to and from the CMU 106 can use an industry standard protocol known as the Aircraft Communications Addressing and Reporting System (ACARS). The ACARS messages can be ACARS safety messages or ACARS non-safety messages. Although not shown, the CMU can also include an application for sending and receiving ACARS messages.

[0025] ACARS safety messages are typically to and from air traffic control (ATC) (without limitation) and may relate to the safety of the aircraft and air traffic control, e.g., permission to change altitude or heading, ATC flight tracking and / or surveillance, etc. Examples of safety messages include, but are not limited to, FANS 1 / A CPDLC, ADS-C, and ARINC 623 ATS (including D-Taxi, D-DepartureClearance, D-Taxi, etc.) messages. ACARS non-safety messages may be operational control messages (e.g., maintenance-related communications, aircraft operational communications, etc.) transmitted to and from airline operators and / or business and general aviation (BGA) operators (e.g., onboard service providers, ground service providers, etc.) (via peer-to-peer servers 120 on the ground 101).

[0026] The CMU 106 can communicate with other avionics on an ARINC-429 (A429) data bus (i.e., a multi-receiver, single-transmitter data bus used by the communication, navigation, surveillance, and / or control equipment of the vehicle 102). The ARINC-429 bus is used to connect to line replaceable units (e.g., radio components and ACARS terminal systems). The A429 bus has a protocol running on it for sending and receiving files / messages, such as ACARS messages. Specifically, the CMU 106 can communicate (e.g., using the A429 data bus) with an optional VHF interface 112, an optional SATCOM interface 114, and / or an optional HF interface (not shown), all of which can be approved for transmitting ACARS safety information. The CMU 106 can be communicatively coupled to the optional VHF interface 112, the optional SATCOM interface 114, and / or the optional HF interface on the VHF port, the SATCOM port, and the HF port of the CMU 106, respectively.

[0027] The optional VHF interface 112 may include a VHF radio component configured to wirelessly transmit at least ACARS messages to and from one or more VHF data link service providers 116 at VHF frequencies (i.e., 30 MHz to 300 MHz). The one or more VHF data link service providers 116 on the ground 101 may receive downlink ACARS messages and route them to an appropriate location, such as ATC or an airline / aircraft operations center, using, for example, a network 118 such as the Internet. The one or more VHF data link service providers 116 may also transmit uplink ACARS messages from an airline operations center or ATC and transmit them to the vehicle 102 via the VHF interface 112 (or SATCOM or HF).

[0028] The optional SATCOM interface 114 may include a SATCOM radio component configured to transmit at least ACARS messages wirelessly to and from one or more SATCOM data link service providers 116 via one or more satellites. One or more SATCOM data link service providers 116 on the ground 101 may receive downlink ACARS messages from the vehicle 102 (via satellite) and route these messages to an appropriate location, for example, using a network 118. One or more SATCOM data link service providers 116 may also transmit uplink ACARS messages from an airline operations center or air traffic controller (ATC) and transmit these messages to the vehicle 102 (via satellite). The SATCOM data link service provider 116 may also interact with an ACARS service provider. In some cases, a SATCOM data link service provider may also be an ACARS service provider.

[0029] The optional HF interface (not shown) may also include an HF radio configured to wirelessly communicate at HF ​​frequencies (i.e., 3 MHz to 30 MHz) with the HF data link service provider 116. In some cases, the HF service provider 116 may also be a VHF service provider 116 and / or a SATCOM service provider 116.

[0030] In some configurations, the preferred subnets for ACARS safety messages (according to the CMU 106) may be (in order of priority, from highest to lowest): VHF, SATCOM, and HF (if present). For example, in areas without VHF service (e.g., over the ocean) or when VHF is unavailable, only (or primarily) SATCOM may be used; and if both VHF and SATCOM are unavailable (e.g., near the Earth's poles), only (or primarily) HF may be used.

[0031] As long as the optional VHF interface 112, the optional SATCOM interface 114, and the optional HF interface (not shown) are present on the vehicle 102, they can each interact with the corresponding security subnet 122A-B (i.e., a subnet approved for transmitting ACARS safety messages). For example, the optional VHF interface 112 communicates through the VHF subnet, etc. It should be noted that the vehicle 102 may not include all of the VHF interface 112, the SATCOM interface 114, and the HF interface, but preferably includes at least one interface to the security subnet 122. In one configuration, the vehicle 102 may include a VHF interface 112 and / or a SATCOM interface 114, but not an HF interface. In this configuration, the AOIP computing device 104 can be communicatively coupled to the CMU 106 on the HF port.

[0032] In some cases, the ACARS service provider is also a HF, VHF and / or SATCOM service provider 116, such as ARINC or SITA. In this case, one or more of the optional VHF interface 112, the optional SATCOM interface 114, and the optional HF interface can interact with the aircraft via VHF, SAT, and HF, and communicate with the AOC center and the air traffic control center.

[0033] Each IP broadband interface 110 may include an IP broadband radio component that is configured to wirelessly communicate with a corresponding peer server 120 (on a corresponding IP subnet), for example, a cellular radio component for communicating on a cellular subnet, a Wi-Fi radio component for communicating via a Wi-Fi subnet, and / or an IP broadband non-ACARS SATCOM radio component (different from the SATCOM interface 114) for communicating on an IP broadband non-ACARS SATCOM subnet. The IP broadband SATCOM subnet can be connected to a ground server, which is then connected to an airline operations center. Cellular, Wi-Fi, and IP broadband non-ACARS SATCOM subnets can be considered non-secure networks 124 because they are not approved for transmitting ACARS safety messages. The vehicle 102 can use different non-secure subnets 124 in different situations, for example, the vehicle 102 can use a cellular subnet and / or a Wi-Fi subnet on the ground 101, and an IP broadband SATCOM subnet in the air. Although cellular, Wi-Fi, and IP broadband non-ACARSSATCOM are discussed herein as exemplary non-secure subnets 124, any packet-based wireless broadband subnet may be used to implement the non-secure subnet 124.

[0034] As described above, the secure subnet 122 (e.g., accessed by the VHF interface 112 and / or the SATCOM interface 114) may each be approved (e.g., approved by the Federal Aviation Administration (FAA)) for transmitting ACARS safety messages, but the non-secure subnet 124 may not be approved for transmitting ACARS safety messages. In addition, the secure subnet 122 may have a relatively low bandwidth, and use of the secure subnet may be expensive when compared to the non-secure subnet 124. Therefore, using the non-secure subnet 124 to transmit ACARS non-safety messages may be efficient and cost-effective.

[0035] The AOIP computing device 104 may act as an aircraft data gateway (ADG), i.e., a server that communicates with a peer server 120 on the ground 101. The AOIP computing device 104 may be implemented using one or more processors 105 that execute instructions stored in a memory. The AOIP computing device 104 may be communicatively coupled to the CMU 106 over a HF (or SATCOM) port of the CMU 106. Thus, the AOIP computing device 104 may appear in the CMU 106 as a HF (or SATCOM) radio component / interface.

[0036] To facilitate the transmission of ACARS non-safety messages on the non-safety subnet 124, the AOIP computing device 104 may also be communicatively coupled to at least one IP broadband interface 110, either directly or via a router 108 (e.g., a GoDirect router). The CMU 106 may perform subnet / interface selection for ACARS messages using a database indicating the priority order of various messages. For example, the CMU 106 may include (or may be communicatively coupled to) a database that designates the HF port of the CMU 106 (which is connected to the AOIP computing device 104) as the highest priority port for ACARS non-safety messages and the lowest priority port for ACARS safety messages. Alternatively, the database may designate the SATCOM port on the CMU 106 (which is connected to the SATCOM interface 114) as the highest priority port for ACARS non-safety messages and the lowest priority port for ACARS safety messages.

[0037] However, a potential problem arises because the AOIP computing device 104 may be connected to the CMU 106 on a port (e.g., an HF port) that is approved for transmission of ACARS safety messages and ACARS non-safety messages from the perspective of the CMU 106, but the AOIP computing device 104 may only have access to the IP broadband interface 110 that is not approved for transmission of ACARS safety messages. For example, when all higher priority ports (e.g., VHF and / or SATCOM) on the CMU 106 are unavailable, the CMU 106 may attempt to route the ACARS safety message through the HF port (which is connected to the AOIP computing device 104) even though the AOIP computing device 104 and the IP broadband interface 110 are not approved for transmission of ACARS safety messages.

[0038] Additionally, the CMU 106 may not transmit subsequent ACARS safety messages until it receives an acknowledgement of the most recently transmitted ACARS safety message. Thus, an untransmitted (and unacknowledged) ACARS safety message may prevent the transmission of subsequent ACARS safety messages for a period of time.

[0039] To prevent and / or minimize these potential problems, the AOIP computing device 104 can determine whether the ACARS message received from the CMU 106 is an ACARS safety message or an ACARS non-safety message. The AOIP computing device 104 can identify the ACARS safety message by looking at the addressing information in the packet header of the ACARS message (i.e., the tag field or subtag field in the packet header).

[0040] In addition, the AOIP computing device 104 can monitor CMU status messages broadcast (e.g., once per second) by the CMU 106 on the A429 data bus. Each CMU status message can be a 32-bit status word on the A429 bus, including a header and a payload. The payload can include a bit for each secure subnet 122 indicating the availability of the corresponding secure subnet 122.

[0041] Prior to receiving an ACARS safety message (and / or determining that all safety subnets 122 are unavailable), the AOIP computing device 104 may be in "available mode." While in available mode, the AOIP computing device 104 may receive ACARS non-safety messages from the CMU 106 and transmit these messages to the peer server 120 via the IP broadband interface 110 and the non-safety subnet 124. In available mode, the AOIP computing device 104 may also transmit (e.g., periodically broadcast) a first status message indicating that the AOIP computing device 104 (and the corresponding port) is in available mode. Each first status message may be a status word transmitted on an A429 bus that is readable by the CMU 106. While in available mode, the AOIP computing device 104 may also discard any ACARS safety messages it receives from the CMU 106.

[0042] In response to receiving an ACARS safety message (and / or determining that all safety subnets 122 are unavailable), the AOIP computing device 104 may periodically transmit a second status message indicating that the AOIP computing device 104 is unavailable. In other words, when the most recently received ACARS message is an ACARS safety message, the AOIP computing device 104 may periodically broadcast a second status message indicating that the AOIP computing device 104 is unable to transmit any message on the at least one IP broadband interface 110. Each second status message may be a status word transmitted on an A429 bus readable by the CMU 106. This AOIP computing device 104 state (i.e., periodically transmitting a second status message) may be referred to herein as an "unavailable mode." The AOIP computing device 104 may also discard any received ACARS safety messages in unavailable mode. Optionally, the AOIP computing device 104 may also need to determine (while the AOIP computing device is in the available mode) that all safety subnets 122 (e.g., VHF interface 112 and / or SATCOM interface 114) are unavailable before transitioning to the unavailable mode. It should be noted that when in the unavailable mode, the AOIP computing device 104 may preferably not transition to the available mode only in response to receiving an ACARS non-safety message (while all safety subnets 122 are still unavailable).

[0043] In response to subsequently determining that at least one of the secure subnets 122 is available, the AOIP computing device 104 may stop transmitting the second status message and instead transmit (e.g., periodically broadcast) the first status message indicating that the AOIP computing device 104 is available. In other words, when at least one secure subnet 122 becomes available (while the AOIP computing device 104 is in the unavailable mode), the AOIP computing device 104 may transition back to the available mode. Optionally, before transitioning from the unavailable mode to the available mode, the AOIP computing device 104 may also need to determine (while the AOIP computing device 104 is in the unavailable mode) that at least one non-secure subnet 124 is available (e.g., by viewing the CMU status message). In the available mode, the AOIP computing device 104 may continue to transmit ACARS non-secure messages (received from the CMU 106) to the peer server 120 while discarding any ACARS secure messages received from the CMU 106.

[0044] The ACARS Over IP system 100 can provide low-cost, high-bandwidth AOIP services on a wide range of aircraft, which originally required a large number of avionics upgrades (i.e., CMU 106 software upgrades) and in many cases require CMU hardware platform upgrades. The AOIP system 100 can work with older CMU / CMF / ATSU. In other words, the ACARS Over IP system 100 described herein can provide an AOIP solution without the need for CMU 106 (or equivalent) upgrades. In addition, the AOIP computing device 104 can also be maintained at Class E and does not have to be certified to, for example, Class D. Utilizing the method described herein, the AOIP computing device 104 can be approved for safety services without verification, which may require about 2 operational flight tests.

[0045] Figure 2 2 is a block diagram illustrating an exemplary AOIP computing device 204 communicatively coupled to an exemplary CMU 206. The AOIP computing device 204 and the CMU 206 may be used to Figure 1 200. The AOIP computing device 204 may be implemented using one or more processors 105 executing instructions stored in a memory. Similarly, the CMU 206 may be implemented using one or more processors 107 executing instructions stored in a memory. The CMU 206 may also be a control management function (CMF), an air traffic service unit (ATSU), an ACARS management unit (MU), etc.

[0046] The AOIP computing device 204 can be communicatively coupled to a CMU 206. The CMU 206 can include a plurality (e.g., at least two, at least three, etc.) of ports 229 for communicatively coupling the CMU 206 to various other interfaces, devices, and / or systems. Each port 229 can be a physical port on the CMU 206 into which a cable connector is plugged.

[0047] The CMU 206 may include (or be communicatively coupled to) a database 230. The database 230 may include data indicating at least one priority of each port 229 for each type of ACARS message. For example, if the CMU 206 has a VHF port 229, a SATCOM port 229, and a HF port 229 (e.g., which is connected to the AOIP computing device 204), the database 230 may include data indicating the priority of each of the VHF port 229, the SATCOM port 229, and the HF port 229 for ACARS safety messages. Similarly, the database 230 may include data indicating the priority of each of the VHF port 229, the SATCOM port 229, and the HF port 229 for ACARS non-safety messages. It should be noted that the priority of a given port 229 for ACARS safety messages may be different from its priority for ACARS non-safety messages. For example, a particular port 229 (e.g., VHF port 229, SATCOM port 229, or HF port 229) may be the lowest priority port 229 for ACARS safety messages and the highest priority port 229 for ACARS non-safety messages. Additionally or alternatively, CMU 206 may be configured in other ways (besides database 230).

[0048] The CMU 206 may also generate CMU status messages using a status message generator 232. The CMU 206 may periodically broadcast CMU status messages on the A429 bus, for example, once per second. The status message may include an indication of the availability (COMM / NO COMM) of each of the subnets 122, 124. The CMU 206 may also monitor the availability of the port 229 and / or the communication interface using a port / interface monitor 234. For example, the CMU 206 may monitor the availability of the VHF port 229, the SATCOM port 229, the HF port 229 (for coupling the AOIP computing device 104 to the CMU 106), the VHF interface 112, the SATCOM interface 114, and / or the IP broadband interface 110, respectively. Monitoring the HF port 229 may include monitoring status messages received from the AOIP computing device 204. The CMU 206 may continuously track the availability of each port 229 and / or communication interface that may be available to the CMU 206 and store indicators related to the availability, such as in the database 230. Thus, the status of the port 229 may be monitored by monitoring status messages, indications of the port 229 (COMM / NO COMM), or higher layer determinations based on the availability of the corresponding data link (COMM / NO COMM). Additionally or alternatively, monitoring the availability of the subnets 122, 124 and / or the port 229 may include, for example, determining whether a downlink message is being acknowledged after a maximum predetermined number of attempts.

[0049] In a first example, the AOIP computing device 204 may be connected to the CMU 206 on the HF port 229, while the CMU 206 is connected to the VHF interface 112 (via the VHF port 229) and the SATCOM interface 114 (via the SATCOM port 229). The HF port 229 may be designated as the lowest priority port 229 (from a subnet selection perspective) for ACARS safety messages and the highest priority port 229 for some (or all) ACARS non-safety messages.

[0050] Prior to receiving any ACARS safety messages (and / or determining that all safety subnets 122 are unavailable), the CMU 206 may transmit ACARS safety messages via a higher priority safety subnet 122 (e.g., VHF or SATCOM), but may transmit ACARS non-safety messages via the HF port 229 to the AOIP computing device 204, which appears as the HF radio component / interface of the CMU 206. The AOIP computing device 204 may use the IP broadband interface 110 to transmit the ACARS non-safety messages via the non-safety subnet 124. The AOIP computing device 204 may also transmit (e.g., periodically broadcast) a first status message indicating that the AOIP computing device 204 is available. The AOIP computing device 204 may also discard any ACARS safety messages received from the CMU 206.

[0051] The AOIP computing device 204 may monitor the availability of the port 229 using a status message monitor 222 that monitors the CMU status messages that are periodically broadcast, for example, once per second. In addition, the AOIP computing device 204 may determine whether a received ACARS message is an ACARS safety message or an ACARS non-safety message using an ACARS message monitor 224 that reads addressing information in a packet header of an ACARS message.

[0052] If all ports 229 that are assigned a higher priority for ACARS safety messages (i.e., the VHF port 229 and the SATCOM port 229) become unavailable, the CMU 206 can send the ACARS safety message to the AOIP computing device 204 via the HF port 229 (because the AOIP computing device 204 appears in the CMU 206 as an HF radio component / interface approved for transmitting ACARS safety messages). Thus, when all higher priority ports 229 for ACARS safety messages (i.e., VHF port 229 and SATCOM port 229) are unavailable and the AOIP computing device 204 receives an ACARS safety message, the AOIP computing device 204 may (1) generate (e.g., using status message generator 226) and broadcast a status message indicating that the AOIP computing device 204 (connected on HF port 229) is unavailable (e.g., by setting a bit in a tag 270 word sent to the CMU 206 via 429 or by stopping transmission of the tag 270 status word); and (2) discard any received ACARS safety information. In an alternative example, the AOIP computing device 204 may immediately broadcast its unavailability once the secure subnet 122 is unavailable. In another alternative example, the AOIP computing device 204 may immediately broadcast its unavailability once the ACARS safety message is received, regardless of the availability of the secure subnet 122 or the non-secure subnet 124.

[0053] After broadcasting its unavailability, the AOIP computing device 204 may monitor the availability status of the secure subnet 122, for example, by looking for the tag 270 CMU status word broadcast by the CMU 206 on the A429 bus. When the VHF port 229 and / or the SATCOM port 229 become available, the AOIP computing device 204 may generate (e.g., using the status message generator 226) and broadcast a message indicating that the AOIP computing device 204 is available again. At this point, ACARS safety messages may be transmitted again on the secure subnet 122 via the VHF port 229 and / or the SATCOM port 229, while ACARS non-safety messages may be transmitted on the non-safe subnet 124 via the HF port 229 (connected to the AOIP computing device 204). Once the AOIP computing device 204 receives the ACARS non-safety message from the CMU 206 (and the AOIP computing device 204 is in the available mode), the AOIP computing device 204 may transmit the ACARS non-safety message to the IP broadband interface 110 via the communication interface 228 .

[0054] In a second example, the AOIP computing device 204 may be connected to the CMU 206 on a SATCOM port 229, while the CMU 206 is connected to the VHF interface 112 (via the VHF port 229). In this example, the CMU 206 may not include the HF port 229. The SATCOM port 229 may be designated as the lowest priority port 229 (from a subnet selection perspective) for ACARS safety messages and the highest priority port 229 for some (or all) ACARS non-safety messages. The CMU 206 may transmit ACARS safety messages via a higher priority subnet (i.e., VHF), but may send ACARS non-safety messages via the AOIP computing device 204, which appears as a SATCOM radio component in the CMU 206.

[0055] Before receiving any ACARS safety messages (and / or determining that all safety subnets 122 are unavailable), the CMU 206 may transmit ACARS safety messages via a higher priority safety subnet 122 (e.g., VHF) and may transmit ACARS non-safety messages (using the IP broadband interface 110) via the non-safety subnet 124. The AOIP computing device 204 may also transmit (e.g., periodically broadcast) a first status message indicating that the AOIP computing device 204 is available. The AOIP computing device 204 may also discard any ACARS safety messages received from the CMU 206.

[0056] If all ports 229 (i.e., VHF ports 229) that are assigned a higher priority for ACARS safety messages become unavailable, the ACARS safety message may be sent to the AOIP computing device 204 via the SATCOM port 229 (because the AOIP computing device 204 appears to the CMU 206 as a SATCOM interface 114 approved for transmission of ACARS safety messages). If all higher priority ports 229 (i.e., VHF ports 229) for ACARS safety messages are unavailable and the AOIP computing device 204 receives the ACARS safety message, the AOIP computing device 204 may discard the ACARS safety message and generate (e.g., using the status message generator 226) and broadcast a second status message indicating that the AOIP computing device 204 is unavailable.

[0057] After broadcasting its unavailability, the AOIP computing device 204 may monitor the availability status of the VHF port 229. When the VHF port 229 becomes available, the AOIP computing device 204 may generate (e.g., using the status message generator 226) and broadcast a first status message indicating that the AOIP computing device 204 is available again. At this point, the ACARS safety message may be transmitted again on the safety subnet 122 via the VHF port 229, while the ACARS non-safety message may be transmitted on the non-safety subnet 124 via the SATCOM port 229 (connected to the AOIP computing device 204). Once the AOIP computing device 204 receives the ACARS non-safety message from the CMU 206 (and the AOIP computing device 204 is in available mode), the AOIP computing device 204 may transmit the ACARS non-safety message to the IP broadband interface 110 via the communication interface 228.

[0058] Figure 3 is a block diagram illustrating the state transitions of the AOIP computing device 104. Specifically, Figure 3 The AOIP computing device 104 is shown switching between an available mode 338 and an unavailable mode 340 in response to various stimuli. It should be noted that Figure 3 The various transitions shown in the figure may occur in a specific order or may not occur in a specific order, and may occur or may not occur at all. For example, the AOIP computing device 104 may transition from the available mode 338 to the unavailable mode 340, and may not transition back to the available mode 338, for example, due to a system failure.

[0059] In the available mode 338, the AOIP computing device 104 may receive ACARS non-safety messages from the CMU 106 and transmit these messages to the peer server 120 over the non-safety subnet 124 using the IP broadband interface 110. In the available mode 338, the AOIP computing device 104 may also transmit (e.g., periodically broadcast) a first status message, such as by transmitting a status word on the A429 data bus readable by the CMU 106, indicating that the AOIP computing device 104 (and the corresponding port 229) is in the available mode 338. When in the available mode, the AOIP computing device 104 may discard any ACARS safety messages received while it is in the available mode 338.

[0060] While in the unavailable mode 340, the AOIP computing device 104 may transmit (e.g., periodically broadcast) a second status message indicating the unavailability of the AOIP computing device 104 (and the corresponding port 229, e.g., the HF port 229 or the SATCOM port 229). The second status message may be transmitted as a status word on the A429 bus that is readable by the CMU 106. The AOIP computing device 104 may also discard all ACARS safety messages and ACARS non-safety messages received from the CMU 106 while it is in the unavailable mode 340.

[0061] After initialization (and before receiving any ACARS safety messages), the AOIP computing device 104 may enter the available mode 338. Because the AOIP computing device 104 may be communicatively coupled to the CMU 106 over the HF (or SATCOM) port 229, the CMU 106 may transmit ACARS safety messages to the AOIP computing device 106 even though the AOIP computing device 104 (and the non-secure subnet 124) may not be approved for transmission of ACARS safety messages.

[0062] To prevent and / or minimize problems associated with ACARS safety messages sent to the AOIP computing device 104, the AOIP computing device 104 may transition to the unavailable mode 340 in response to receiving the ACARS safety message. Optionally, the AOIP computing device 104 may also be required to determine that all safety subnets 122 are unavailable (e.g., by viewing the CMU status message) before transitioning to the unavailable mode 340. In other words, the AOIP computing device 104 may transition to the unavailable mode 340 when the most recently received ACARS message is an ACARS safety message and all safety subnets 122 are unavailable.

[0063] When in the unavailable mode 340, the AOIP computing device 104 may preferably not transition to the available mode 338 in response to receiving an ACARS non-secure message while all secure subnets 122 are still unavailable (e.g., as indicated in the latest CMU status message). In other words, as long as all secure subnets 122 are still unavailable, the AOIP computing device 104 may remain in the unavailable mode 340 even if it receives an ACARS non-secure message. Similarly, the AOIP computing device 104 may remain in the unavailable mode 340 even if one or more secure subnets 122 become available while all non-secure subnets 124 are unavailable, i.e., the AOIP computing device 104 may transition to the available mode 338 only when at least one non-secure subnet 124 is available.

[0064] While in the unavailable mode 340, the AOIP computing device 104 may transition to the available mode 338 in response to determining that at least one secure subnet 122 is available (e.g., by viewing a CMU status message). Optionally, the AOIP computing device 104 may also need to determine that at least one non-secure subnet 124 is available before transitioning to the available mode 338. In other words, when at least one secure subnet 122 (and optionally at least one non-secure subnet 124) is available (while the AOIP computing device 104 is in the unavailable mode 340), the AOIP computing device 104 may transition back to the available mode 338.

[0065] Figure 4 is a flow chart illustrating an exemplary computerized method 400 for transmitting an ACARS non-safety message using an AOIP computing device 104. The method 400 may be performed by at least one processor 105 executing instructions in memory (eg, at least one processor 105 and memory in the AOIP computing device 104).

[0066] The AOIP computing device 104 may be communicatively coupled to the CMU 106, for example, on a CMU port 229 (e.g., VHF, SATCOM, or HF) that is designated as the lowest priority port 229 for ACARS safety messages and the highest priority port 229 for ACARS non-safety messages. The AOIP computing device 104 may also be communicatively coupled to an IP broadband interface 110 that may be used to transmit ACARS non-safety messages via the non-safety subnet 124. In other words, the AOIP computing device 104 may be connected to the CMU 106 on a port 229 that is approved for transmission of ACARS safety messages and ACARS non-safety messages, but the AOIP computing device 104 may only have access to one or more communication interfaces (i.e., the IP broadband interface 110) that are not approved for transmission of ACARS safety messages.

[0067] The at least one processor 105 may be configured to determine 402 whether the ACARS message received from the CMU 106 is an ACARS safety message or an ACARS non-safety message. The at least one processor 105 may identify the ACARS safety message by looking at the addressing information in the packet header of the ACARS message (i.e., the tag field or the tag and subtag fields (e.g., multiple 32-bit status words) in the header of the ACARS message transmitted on the A429 bus).

[0068] The at least one processor 105 may also be configured to monitor 404 the availability of one or more secure subnets 122. For example, the at least one processor 105 may monitor CMU status messages broadcast by the CMU 106 (e.g., once per second on the A429 data bus). The status of the secure subnets 122 may also be determined in other ways (e.g., directly listening to the radio to obtain radio status). Each CMU status message may be a 32-bit status word transmitted on the A429 bus, including a header and a payload. The payload may include bits indicating the availability of each secure subnet 122, for example, two bits for two secure subnets 122 accessible to the CMU 106.

[0069] The at least one processor 105 may also be configured to transmit 406 a first status message indicating that the AOIP computing device 104 is available before receiving any ACARS safety message (and optionally determining that all safety subnets 122 are unavailable). The at least one processor 105 may also be configured to transmit an ACARS non-safety message to the peer server 120 via at least one non-safety subnet 124 as long as the AOIP computing device does not receive an ACARS safety message. The at least one processor 105 may also be configured to discard any ACARS safety message received from the CMU 106.

[0070] The at least one processor 105 may also be configured to periodically transmit 408 a second status message indicating that the AOIP computing device 104 is unavailable in response to receiving the ACARS safety message. Optionally, the AOIP computing device 104 may also need to (when the AOIP computing device 104 is in unavailable mode) determine that all safety subnets 122 are unavailable before transmitting the second status message (e.g., by checking the CMU status message). The at least one processor 105 may also be configured to discard all received ACARS safety messages at this time.

[0071] The at least one processor 105 may also be configured to, in response to determining that at least one secure subnet 124 is available (e.g., by checking CMU status messages), stop 410 periodically transmitting the second status message, and instead transmit the first status message indicating that the AOIP computing device 104 is available. Optionally, the AOIP computing device 104 may also need to (when the AOIP computing device 104 is in the unavailable mode) determine that at least one non-secure subnet 124 is available (e.g., by checking CMU status messages) before stopping transmitting the second status message and resuming transmitting the first status message.

[0072] Figure 5is a flow chart illustrating an exemplary computerized method 500 for transmitting an ACARS non-safety message using an AOIP computing device 104. The method 500 may be performed by at least one processor 105 executing instructions in memory (eg, at least one processor 105 and memory in the AOIP computing device 104).

[0073] The AOIP computing device 104 may be communicatively coupled to the CMU 106, for example, on a CMU port 229 (e.g., VHF, SATCOM, or HF) that is designated as the lowest priority port 229 for ACARS safety messages and the highest priority port 229 for ACARS non-safety messages. The AOIP computing device 104 may also be communicatively coupled to an IP broadband interface 110 that may be used to transmit ACARS non-safety messages via the non-safety subnet 124. In other words, the AOIP computing device 104 may be connected to the CMU 106 on a port 229 that is approved for transmission of ACARS safety messages and ACARS non-safety messages, but the AOIP computing device 104 may only have access to one or more communication interfaces (i.e., the IP broadband interface 110) that are not approved for transmission of ACARS safety messages.

[0074] Optionally, the at least one processor 105 may be configured to initialize 502 the AOIP computing device 104. This may include powering up the AOIP computing device 104 and / or executing a boot sequence of instructions (e.g., after installation or repair, a soft reset, and / or a hard reset of the AOIP computing device 104). Alternatively, the AOIP computing device 104 may already be running without requiring initialization.

[0075] The at least one processor 105 can be configured to enter 504 an available mode in which the AOIP computing device 104 can: (1) transmit (e.g., periodically broadcast) a first status message indicating that the AOIP computing device 104 (and the corresponding port 229) is in the available mode 338; (2) receive ACARS non-safety messages from the CMU 106 and transmit these messages to the peer server 120 via the non-safety subnet 124; and (3) discard any received ACARS safety messages. Each first status message can be a 32-bit status word transmitted on the A429 data bus.

[0076] The at least one processor 105 may also be configured to transition 506 to the unavailable mode 340 in response to receiving an ACARS safety message. Optionally, the at least one processor 105 may also be configured to (when the AOIP computing device is in the available mode) determine that all safety subnets 122 (e.g., the VHF interface 112 and / or the SATCOM interface 114) are unavailable before transitioning to the unavailable mode. In the unavailable mode 340, the AOIP computing device 104 may: (1) transmit (e.g., periodically broadcast) a second status message indicating that the AOIP computing device 104 is in the unavailable mode; and (2) discard any ACARS safety messages. The second status message may be a 32-bit status word transmitted on the A429 data bus.

[0077] When in the unavailable mode 340, the AOIP computing device 104 may preferably not transition to the available mode 338 in response to receiving an ACARS non-secure message while all secure subnets 122 are still unavailable (as indicated in the latest CMU status message). In other words, as long as all secure subnets 122 are still unavailable, the AOIP computing device 104 may remain in the unavailable mode 340 even if it receives an ACARS non-secure message. Similarly, the AOIP computing device 104 may remain in the unavailable mode 340 even if one or more secure subnets 122 become available while all non-secure subnets 124 are unavailable, i.e., the AOIP computing device 104 may transition to the available mode 338 only when at least one non-secure subnet 124 is available.

[0078] The at least one processor 105 may also be configured to transition 508 back to the available mode 338 in response to determining that the at least one secure subnet 122 is available (e.g., by viewing a CMU status message). Optionally, before transitioning from the unavailable mode to the available mode, the at least one processor 105 may also be configured to determine (while the AOIP computing device 104 is in the unavailable mode) that the at least one non-secure subnet 124 is available (e.g., by viewing a CMU status message). In other words, when the at least one secure subnet 122 (and optionally the at least one non-secure subnet 124) is available (while the AOIP computing device 104 is in the unavailable mode 340), the AOIP computing device 104 may transition back to the available mode 338.

[0079] Electronic equipment overview

[0080] The configuration of the present disclosure includes the various steps and operations described above. Many of these steps and operations can be performed by hardware components, or can be included in machine executable instructions, which can be used to make a general or special processor programmed with instructions perform these steps. Alternatively, these steps can be performed by a combination of hardware, software and / or firmware.

[0081] therefore, Figure 6 1 is a block diagram illustrating an example of an electronic device that may be used in some configurations of the present disclosure. The illustrated components may be located within the same physical structure, or in separate housings or structures. The AOIP computing device 104, CMU 106, router 108, one or more peer servers 120, and / or data link service provider 116 described above may use Figure 6 One or more of the electronic devices 602 described in the embodiment of the present invention. The electronic device 602 includes a processor 610. The processor 610 may be a general-purpose single-chip or multi-chip microprocessor (e.g., ARM), a dedicated microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc. The processor 610 may be referred to as a central processing unit (CPU). Although in Figure 6 Only a single processor 610 is shown in the electronic device 602, but in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

[0082] The electronic device 602 also includes a memory 604 that communicates electronically with the processor 610. That is, the processor 610 can read information from the memory 604 and / or write information to the memory. The memory 604 can be any electronic component that can store electronic information. The memory 604 can include a machine-readable medium (also referred to as a computer-readable medium) on which instructions that can be used to program a computer (or other electronic device) to perform a process are stored. The machine-readable medium can include, for example, a floppy disk, an optical disk, a compact disc read-only memory (CD-ROM), a digital video disc (DVD), a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or an optical card, a flash memory, or other types of media / machine-readable media suitable for storing electronic instructions. The machine-readable medium can be tangible and non-transient.

[0083] Data 608a and instructions 606a may be stored in memory 604. Instructions 606a may include one or more programs, routines, subroutines, functions, processes, etc. Instructions 606a may include a single computer-readable statement or many computer-readable statements. The instructions 606a may be executed by processor 610 to implement one or more of the methods, functions, and processes described above. Executing instructions 606a may involve using data 608a stored in memory 604. Figure 6 Some instructions 606b and data 608b are shown loaded into processor 610 (which may come from instructions 606a and data 608a).

[0084] The electronic device 602 may also include one or more communication interfaces 612 for communicating with other electronic devices. The communication interface 612 may be based on wired communication technology, wireless communication technology, or both. Examples of different types of communication interfaces 612 include serial ports, parallel ports, universal serial buses (USB), Ethernet adapters, IEEE 1394 bus interfaces, small computer system interface (SCSI) bus interfaces, infrared (IR) communication ports, Bluetooth wireless communication adapters, and the like. For example, the CMU 106 may interact with a multi-function control display unit (MCDU) human-machine interface (HMI).

[0085] The electronic device 602 may also include one or more input devices 614 and one or more output devices 618, for example, for use with a user interface. Examples of different types of input devices 614 include keyboards, mice, microphones, camera remote control devices, buttons, touch screens, etc. For example, the electronic device 602 may include one or more microphones 616 that convert acoustic signals (e.g., voice, sound) into electrical or electronic signals. In another example, a camera may track the position and / or movement of an object and convert images / videos into instructions to control other devices. Examples of different possible output devices 618 include speakers, printers, display devices, etc.

[0086] The various components of the electronic device 602 may be coupled together via one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For simplicity, Figure 6 The various buses are shown as bus system 626. Additionally, various other architectures and components may be used in conjunction with any of the electronic devices described herein.

[0087] the term

[0088] Brief definitions of terms, abbreviations and phrases used throughout this application are given below.

[0089] The term "determining" may include evaluating, calculating, processing, deriving, investigating, searching (e.g., searching in a table, database, or other data structure), ascertaining, etc. Additionally, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Additionally, "determining" may include resolving, selecting, choosing, establishing, etc.

[0090] Unless explicitly stated otherwise, the phrase "based on" does not mean "based only on". In other words, the phrase "based on" describes both "based only on" and "based at least on". In addition, the term "and / or" means "and" or "or". For example, "A and / or B" can mean "A", "B", or "A and B". In addition, "A, B, and / or C" can mean "only A", "only B", "only C", "A and B", "A and C", "B and C", or "A, B, and C".

[0091] The terms "connected," "coupled," and "communicatively coupled," and related terms are used in an operational sense, but are not necessarily limited to direct physical connections or couplings. Thus, for example, two devices may be coupled directly, or may be coupled via one or more intermediate media or devices. As another example, devices may be coupled in a manner that enables information to be passed between them without sharing any physical connection with each other. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate that there are various ways of connecting or coupling according to the foregoing definitions.

[0092] The phrases "in an exemplary configuration," "in an exemplary configuration," "in some configurations," "according to some configurations," "in the illustrated configuration," "in other configurations," "configuration," "in an example," "example," "in some examples," "some examples," and the like generally indicate that the particular feature, structure, or characteristic following the phrase is included in at least one configuration of the present disclosure, and may be included in more than one configuration of the present disclosure. Additionally, such phrases do not necessarily refer to the same configuration or different configurations.

[0093] If the specification states a component or feature "may," "could," "would," or "might" be included or have a property, that particular component or feature is not required to be included or have that property.

[0094] The terms "responsive" or "in response to" may indicate that an action is performed fully or partially in response to another action.

[0095] The term "module" refers broadly to a software, hardware, circuit, or firmware (or any combination thereof) component. A module is typically a functional component that generates usable data or other output from a specified input or inputs. Modules may or may not be self-contained. An application (also referred to as an "application") may include one or more modules, or a module may include one or more applications.

[0096] In addition, for the purpose of illustration, various configurations of the present disclosure have been described herein in the context of computer programs, physical components, and logical interactions within a modern computer network. Importantly, although these configurations describe various configurations of the present disclosure related to modern computer networks and programs, the methods and devices described herein are equally applicable to other systems, devices, and networks that will be understood by those skilled in the art. Therefore, the illustrative application of the configurations of the present disclosure is not intended to be limiting, but rather to be taken as an example. Other systems, devices, and networks to which the configurations of the present disclosure may be applicable include, for example, other types of communications and computer devices and systems. More specifically, these configurations are applicable to communication systems, services, and devices such as mobile phone networks and compatible devices. In addition, these configurations are applicable to all levels of computing from personal computers to large network hosts and servers.

[0097] In the above description, reference numerals are sometimes used in conjunction with various terms. Where a term is used in conjunction with a reference numeral, this may refer to a specific element shown in one or more of the accompanying drawings. Where a term is used without a reference numeral, this may refer generally to the term without limitation to any particular accompanying drawing.

[0098] The method disclosed herein includes one or more steps or actions for implementing the described method. Without departing from the scope of the claims, the method steps and / or actions may be interchangeable with each other. In other words, unless the correct operation of the method being described requires a specific sequence of steps or actions, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0099] In summary, the present disclosure provides new systems, methods and arrangements for ACARS Over IP systems for non-safety messages. Although specific embodiments of one or more configurations of the present disclosure have been given above, various alternatives, modifications and equivalents will be apparent to those skilled in the art without departing from the essence of the present disclosure. For example, although the above configurations relate to specific features, functions, processes, components, elements and / or structures, the scope of the present disclosure also includes configurations with different combinations of features, functions, processes, components, elements and / or structures and configurations that do not include all described features, functions, processes, components, elements and / or structures. Therefore, the scope of the present disclosure is intended to cover all such alternatives, modifications and variations that fall within the scope of the appended claims, as well as all equivalents of the present disclosure. Therefore, the above description should not be considered restrictive.

[0100] Exemplary embodiments

[0101] Embodiment 1 includes a communication system in an aircraft, the communication system comprising: a communication management unit (CMU) coupled to at least one secure subnet and an IP-based aircraft communications addressing and reporting system (ACARS) over IP (AOIP) computing device; an AOIP computing device, wherein the AOIP computing device is coupled to at least one non-secure subnet, wherein the AOIP computing device determines whether an ACARS message received from the CMU is an ACARS secure message or an ACARS non-secure message; wherein the AOIP computing device monitors CMU status messages from the CMU; wherein in response to the AOIP computing device receiving the ACARS secure message, the AOIP computing device periodically transmits a second status message, the second status message indicating that the AOIP computing device is unavailable; and wherein in response to determining that at least one secure subnet is available, the AOIP computing device stops periodically transmitting the second status message and transmits a first status message, the first status message indicating that the AOIP computing device is available.

[0102] Embodiment 2 includes the communication system of embodiment 1, wherein the AOIP computing device further periodically transmits a second status message in response to determining that all secure subnets are unavailable, the second status message indicating that the AOIP computing device is unavailable.

[0103] Embodiment 3 includes the communication system of any one of embodiments 1-2, wherein the AOIP computing device further stops periodically transmitting the second status message in response to determining that at least one of the at least one non-secure subnet is available.

[0104] Embodiment 4 includes the communication system of any one of embodiments 1 to 3, wherein the AOIP computing device transmits a first status message indicating that the AOIP computing device is available prior to receiving any ACARS safety message.

[0105] Embodiment 5 includes the communication system of any one of embodiments 1 to 4, wherein the AOIP computing device further transmits the ACARS non-safety message to the peer server via the at least one non-safety subnet prior to receiving any ACARS safety message.

[0106] Embodiment 6 includes the communication system of any one of Embodiments 1 to 5, wherein the CMU is communicatively coupled to the AOIP computing device on a port designated as a lowest priority port for ACARS safety messages and a highest priority port for ACARS non-safety messages.

[0107] Embodiment 7 includes the communication system of embodiment 6, wherein the port for communicatively coupling the AOIP computing device to the CMU is approved for transmission of ACARS safety messages and ACARS non-safety messages, wherein the AOIP computing device is not approved for transmission of ACARS safety messages.

[0108] Embodiment 8 includes a computerized method for transmitting an Aircraft Communications Addressing and Reporting System (ACARS) Over IP (AOIP) computing device using an ACARS non-safety message, the method comprising: determining whether an ACARS message received from a CMU is an ACARS safety message or an ACARS non-safety message; monitoring a CMU status message from the CMU; in response to receiving an ACARS safety message, periodically transmitting a second status message, the second status message indicating that the AOIP computing device is unavailable; and in response to determining that at least one safety subnet is available, ceasing to periodically transmit the second status message and transmitting a first status message, the first status message indicating that the AOIP computing device is available.

[0109] Embodiment 9 includes the computerized method of embodiment 8, wherein in response to determining that all secure subnets are unavailable, further performing periodically transmitting a second status message indicating that the AOIP computing device is unavailable.

[0110] Embodiment 10 includes the computerized method of any one of embodiments 8-9, wherein in response to determining that at least one of the at least one non-secure subnet is available, ceasing to periodically transmit the second status message is further performed.

[0111] Embodiment 11 includes the computerized method of any one of embodiments 8 to 10, further comprising: prior to receiving any ACARS safety message, transmitting a first status message indicating that the AOIP computing device is available.

[0112] Embodiment 12 includes the computerized method of any one of Embodiments 8 to 11, further comprising: transmitting an ACARS non-safety message to a peer server via the at least one non-safety subnet prior to receiving any ACARS safety message.

[0113] Embodiment 13 includes a computerized method according to any one of embodiments 8 to 12, wherein the CMU is communicatively coupled to the AOIP computing device on a port designated as a lowest priority port for ACARS safety messages and a highest priority port for ACARS non-safety messages.

[0114] Embodiment 14 includes the computerized method of embodiment 13, wherein a port for communicatively coupling the AOIP computing device to the CMU is approved for transmission of ACARS safety messages and ACARS non-safety messages, wherein the AOIP computing device is not approved for transmission of ACARS safety messages.

[0115] Embodiment 15 includes an aircraft communications addressing and reporting system (ACARS) Over IP (AOIP) computing device, which is coupled to a communication management unit (CMU) and at least one non-safety subnet, including: at least one processor, the at least one processor configured to: determine whether an ACARS message received from the CMU is an ACARS safety message or an ACARS non-safety message; monitor CMU status messages from the CMU; in response to receiving an ACARS safety message and / or a CMU status message indicating that all safety subnets are unavailable, periodically transmit a second status message, the second status message indicating that the AOIP computing device is unavailable; and in response to determining that the at least one safety subnet is available, stop periodically transmitting the second status message and transmit a first status message, the first status message indicating that the AOIP computing device is available.

[0116] Embodiment 16 includes the AOIP computing device of embodiment 15, wherein the at least one processor is further configured to: further in response to determining that at least one of the at least one non-secure subnet is available, stop periodically transmitting the second status message.

[0117] Embodiment 17 includes the AOIP computing device of embodiment 15, wherein the at least one processor is further configured to: transmit a first status message indicating that the AOIP computing device is available before receiving any ACARS safety message.

[0118] Embodiment 18 includes the AOIP computing device of embodiment 15, wherein the CMU is communicatively coupled to the AOIP computing device on a port designated as a lowest priority port for ACARS safety messages and a highest priority port for ACARS non-safety messages.

[0119] Embodiment 19 includes the AOIP computing device of embodiment 18, wherein a port for communicatively coupling the AOIP computing device to the CMU is approved for transmission of ACARS safety messages and ACARS non-safety messages, wherein the AOIP computing device is not approved for transmission of ACARS safety messages.

[0120] Embodiment 20 includes the AOIP computing device of any one of Embodiments 15 to 19, wherein the AOIP computing device is connected to the CMU on a high frequency (HF) port that is approved from the perspective of the CMU for transmission of ACARS safety messages and ACARS non-safety information.

Claims

1. A communication system (100) in an aircraft (102), comprising: A communication management unit (CMU) (106) coupled to at least one secure subnet (122) and an aircraft communications addressing and reporting system (AOIP) (ACARS Over IP) computing device (104); The AOIP computing device (104), wherein the AOIP computing device (104) is coupled to at least one non-secure subnet (124), wherein the AOIP computing device (104) determines whether the ACARS message received from the CMU (106) is an ACARS safety message or an ACARS non-safety message; wherein the AOIP computing device (104) monitors CMU (106) status messages from the CMU (106); wherein in response to the AOIP computing device (104) receiving an ACARS safety message, the AOIP computing device (104) periodically transmits a second status message, the second status message indicating that the AOIP computing device (104) is unavailable; and In response to determining that at least one secure subnet (122) is available, the AOIP computing device (104) stops periodically transmitting the second status message and transmits a first status message, wherein the first status message indicates that the AOIP computing device (104) is available.

2. The communication system (100) of claim 1, wherein the AOIP computing device (104) further periodically transmits a second status message in response to determining that all secure subnets (122) are unavailable, the second status message indicating that the AOIP computing device (104) is unavailable.

3. A computerized method for transmitting an Aircraft Communications Addressing and Reporting System (ACARS Over IP) (AOIP) computing device (104) an ACARS (100) non-safety message, comprising: determining whether an ACARS message received from a communication management unit CMU (106) is an ACARS safety message or an ACARS non-safety message; monitoring CMU (106) status messages from the CMU (106); In response to receiving an ACARS safety message, periodically transmitting a second status message indicating that the AOIP computing device (104) is unavailable; as well as In response to determining that at least one secure subnet (122) is available, periodically transmitting the second status message is stopped and a first status message is transmitted, the first status message indicating that the AOIP computing device (104) is available.

Images