Distributed method of data acquisition in an AFDX network

Abstract

The subject matter disclosed herein relates to a frame switch of an AFDX network in which the data acquisition application is decentralized. When the switch has to acquire the data transmitted on a virtual link, the switching table contains, apart from the input port and the output port (s) taken by this link, an ID representing the MAC address of the switch. The frames of this link are then not only switched but also transmitted to the network interface of the switch and processed by a dedicated application (DDA), hosted inside the switch. This application can be interrogated by a remote server and transfer the data that it has stored locally.

Claims

1. A frame switch of an Avionics Full-Duplex Switched Ethernet (AFDX) network comprising a plurality of input ports and a plurality of output ports, a switching table comprising a plurality of entries, each entry corresponding to a virtual link passing through the switch and providing, for a virtual link ID (VL.sub.Id) for the virtual link, the input port and the output port(s) taken by this virtual link, a switching module circuit configured for switching any frame arriving on an input port of the frame switch, for reading the virtual link ID contained in a header of the frame and for switching the frame towards the output port(s) given by the entry in the switching table corresponding to this virtual link, a network interface configured for receiving frames intended for the frame switch, wherein: at least one entry of the switching table, corresponding to a predetermined virtual link, furthermore comprises an ID of a media access control (MAC) address of the frame switch; the switching module circuit is configured to transmit at least one frame received on the predetermined virtual link to the network interface of the frame switch; and the frame switch transmits the at least one frame received on the predetermined virtual link to a distributed data application (DDA) hosted by the frame switch to locally store at least part of the frame data of the at least one frame, and wherein transmitting the at least one frame comprises, in response to determining that the at least one frame corresponds to the predetermined virtual link with the ID of the MAC address of the frame switch, transmitting the at least one frame through an Internet Protocol (IP) layer and through a transport layer of a protocol stack of the frame switch to the distributed data application, wherein the distributed data application receives a data acquisition request from a remote server, the data acquisition request giving at least one virtual link for which data are to be acquired, the distributed data application updating the switching table by adding for this virtual link, the ID of the MAC address of the frame switch.

2. A frame switch according to claim 1, wherein the distributed data application locally stores at least part of the frame data with an ID of the predetermined virtual link to which the at least one frame belongs.

3. The frame switch according to claim 1, configured such that the distributed data application recovers, from an ID of the predetermined virtual link, from an IP address, from a user datagram protocol (UDP) port and from a segment ID in a UDP packet, said part of the frame data, and stores said part of the frame data locally, with said ID of the predetermined virtual link, said IP address, said UDP port and said segment ID.

4. The frame switch according to claim 2, wherein the distributed data application compresses the part of the frame data before storing it locally.

5. The frame switch according to claim 1, wherein the data acquisition request furthermore comprises an IP address, a user datagram protocol (UDP) port and a segment ID in a UDP packet.

6. The frame switch according to claim 1, wherein the distributed data application receives a data transfer request from the remote server, the data transfer request comprising at least one virtual link ID whose data are to be transferred, the distributed data application transferring said data in Ethernet frames via a gateway hosted by the frame switch.

7. The frame switch according to claim 1, wherein the distributed data application is configured to receive a data transfer request from the remote server, the data transfer request comprising at least one virtual link ID whose data are to be transferred, said application transferring said data in AFDX frames via a virtual link linking the frame switch to said remote server.

8. An AFDX network comprising a plurality of frame switches according to claim 1.

9. An AFDX network according to claim 8, comprising a server subscribed to said network, the server being configured to transmit at least one data acquisition request to each frame switch of said plurality of frame switches, the at least one data acquisition request being parameterized by at least one ID of a virtual link passing through the frame switch.

10. An AFDX network according to claim 9, wherein the data acquisition request is furthermore parameterized by an IP address, a user datagram protocol (UDP) port and a segment ID in a UDP packet.

11. An AFDX network according to claim 8, furthermore comprising a server subscribed to said network, the server being configured to transmit data transfer requests to each frame switch of said plurality, a data transfer request being parameterized by at least one virtual link ID whose data are to be transferred.

12. An AFDX network according to claim 11, wherein the data transfer request is furthermore parameterized by an IP address, a user datagram protocol (UDP) port and a segment ID in a UDP packet.

13. An aircraft comprising an AFDX network according to claim 8.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other features and advantages of the subject matter disclosed herein will become apparent upon reading preferred embodiments of the subject matter disclosed herein, offered with reference to the appended figures among which:

(2) FIG. 1 represents an example of a known AFDX network of the state of the art;

(3) FIG. 2 schematically represents the internal architecture of an AFDX switch;

(4) FIG. 3 schematically represents an AFDX network to which a centralized data acquisition unit is subscribed;

(5) FIG. 4 represents the implementation of the data acquisition application inside the control module of an AFDX switch according to an embodiment of the subject matter disclosed herein; and

(6) FIG. 5 represents an example of a switching table used by an AFDX switch according to an embodiment of the subject matter disclosed herein.

DETAILED DESCRIPTION

(7) A basic idea of the subject matter disclosed herein is to implement decentralized (or distributed) data acquisition at the level of each switch of the AFDX network and more precisely to host a data acquisition application inside each switch.

(8) Consider again an AFDX network including a plurality of switches, each switch having the internal architecture described with reference to FIG. 2. A plurality of terminals is subscribed to this network and exchanges AFDX frames by virtual links, in a manner known per se.

(9) Using a protocol stack, FIG. 4 represents the manner in which the data acquisition application is implemented inside the network interface (End System E/S) of the switch.

(10) The lowest protocol layer corresponds to the physical layer PHY of the network interface. It is overlaid by the AFDX link layer. When receiving, the latter is adapted to receive the AFDX frames via the internal bus of the switch. When sending, it regulates the transmission of the AFDX frames on the network so as to comply with the bandwidth constraints for the various virtual links. The third layer corresponds to the IP (Internet Protocol) layer of the network interface. When receiving, it is responsible for the CRC (Cyclic Redundancy Check) verification of the IP datagrams (IP checksum) and, where applicable, for defragmentizing to reconstitute the UDP (User Datagram Protocol) packets. When sending, it is in charge of the fragmentizing of the UDP packets into IP datagrams, of the computation and concatenation of the CRC to the datagrams, then of the concatenation of the Ethernet frame header (comprising the virtual link ID.)

(11) The fourth layer corresponds to the UDP layer of the network interface. This layer provides communications logic ports to the applications hosted by the switch.

(12) Above the transport layer (UDP layer) examples of applications being able to be hosted by the switch are represented. The logic ports provided by the underlying UDP layer allow these applications to communicate with remote applications via the AFDX network.

(13) Thus, an SNMP (Simple Network Management Protocol) agent can dialogue with the network supervisor and provide data relating to the management of the switch. An Arinc 615A module enables new data to be downloaded into the switch, for example a new switching table, via the AFDX network.

(14) Finally, according to an embodiment of the subject matter disclosed herein, an application denoted DDA (for Distributed Data Application) is in charge of acquiring the data it receives on certain virtual links. This application can notably dialogue with a remote server in charge of the centralization of the data thus acquired, of their mass storage and, where applicable, of the presentation of these data by a HMI interface. The DDA application can also receive requests from this server to acquire, or on the contrary, to cease to acquire data over a given virtual link. It thus manages a list of virtual links VLS.sup.a={VL.sub.1.sup.a, . . . VL.sub.N.sup.a} passing through the switch and whose data it has to acquire.

(15) FIG. 5 represents an example of a switching table used by an AFDX switch according to an embodiment of the subject matter disclosed herein.

(16) This table contains the list of virtual links that the AFDX switch has to switch. This list is composed of two sub-lists: a first sub-list VLS.sup.a of virtual links whose data are to be acquired and a second sub-list VLS.sup.na of virtual links whose data are not to be acquired. For example, the first list can be composed of virtual links transporting avionics data in the sense defined above.

(17) It can be seen that to each virtual link VL.sub.1.sup.na, . . . VL.sub.P.sup.na of the sub-list VLS.sup.na there corresponds an entry in the switching table. At this entry are stored the input port and the output port(s) of the switch that are taken by the virtual link. It will be understood that when several output ports are stored in an entry of the table, the virtual link is of multicast (or multipoint) type.

(18) Similarly, to each virtual link VL.sub.1.sup.a, . . . VL.sub.N.sup.a of the sub-list VLS.sup.a there corresponds an entry in the switching table at which are stored the input port and the output port(s) of the switch that are taken by the virtual link. However, unlike the previous case, each entry furthermore comprises, following the output port (s), an ID.sub.Id(E/S) representing the internal bus or, equivalently, the MAC address of the switch.

(19) Thus, a frame received on a virtual link VL.sub.n.sup.a of VLS.sup.a is not only switched towards the output port(s) featuring in the table, but also transmitted via the internal bus to the network interface (E/S) of the switch.

(20) Just like the network interface of any subscriber, the network interface of the switch rejects frames belonging to virtual links of which it is not the destination. To do this, it has a filtering table comprising the IDs of the virtual links of which it is effectively the destination. This table notably contains the IDs of the virtual links whose data is to be acquired, namely, VL.sub.1.sup.a_Id, . . . , VL.sub.N.sup.a_Id, as will be explained further on.

(21) Furthermore, the switching module rejects any frame whose virtual link is not listed in the switching table or whose input port is not the one indicated in the table for the virtual link in question. In this way it is ensured that only the virtual links passing through the correct input port of the switch and belonging to the sub-list VLS.sup.a are duplicated towards the network interface of the switch.

(22) When the network interface receives a frame whose virtual link has for destination the switch itself (such a virtual link is for example used for updating the switching table), the latter transmits it, through the protocol stack, to the IP address and to the UDP port of the application that are specified in the frame. When the IP address and/or the UDP port specified in the frame are not recognized by the network interface, the latter supposes that it is a frame to be acquired and transmits it to the UDP port of the DDA application in charge of the acquisition of the frame and of its possible processing.

(23) In a variant, the network interface operates in promiscuous mode, i.e. does not carry out any filtering of frames based on the virtual link IDs, the switching module continuing, however, to ensure the rejection of any frame whose virtual link is not listed in the switching table, as explained previously. In this case, filtering is only ensured by the switching module. The frames received by the network interface are transmitted to the IP address and to the UDP port that are specified in the frame, as previously indicated. Here again, if the IP address and/or the UDP port are not recognized, the frame is transmitted to the DDA application.

(24) On request from the remote server in charge of the centralization of the acquired data, the DDA application recovers and stores at least part of the data contained in the frames belonging to a virtual link VL.sub.n.sup.a and stores them locally in a buffer for later retransmission.

(25) In a variant, the acquired data are stored locally in a memory. In this case, the acquired data are advantageously compressed using a data compression algorithm, known per se, before they are stored. The storage can furthermore be subordinated to the arising of a particular event or to the request from the remote server in charge of the centralization of the acquired data.

(26) The DDA application can receive from the remote server a request giving a list of the virtual link IDs whose data are to be acquired, and updates the switching table by adding the ID of the MAC address of the switch for each of the virtual links of the list. Furthermore, the IDs of the virtual links in question are also added to the filtering table of the network interface of the switch.

(27) Alternatively, the remote server can send a specific request for the acquisition of each virtual link, ordering an acquisition or on the contrary the cessation of this acquisition on this link. It is understood that the updating of the switching table and of the filtering table is then carried out on a case per case basis.

(28) An acquisition request can indicate for any virtual link, the IP address, the UDP port, or even the segment of the “data” field of the packet, corresponding to the data to be acquired. The segment can be identified by its start address and its length. It is thus understood that the DDA application can thus selectively extract the interesting data using a filtering operation controlled by the remote server. The quantity of data to be stored locally and to be retransmitted to the remote server is reduced by that amount.

(29) The format of an acquisition request transmitted to the switch can take the following form:
acquisition_request(VL_Id,[IP_address],[UDP_port],[start_bit,length])
where the parameters between square brackets are optional. The acquired data are stored with the virtual link ID and, where applicable, the IP address, the UDP port and the segment ID in the UDP packet.

(30) The stored data can be transmitted, either in AFDX frames, via a virtual link linking the switch to the server, or in single Ethernet frames (therefore without reservation of bandwidth) via a gateway hosted by the switch. In the first case, the bandwidth allocation gap (BAG) on the virtual link will be chosen small enough so as not to have to restrict the bandwidths allocated to the other virtual links. In the second case, the Ethernet frames are transmitted in the non-allocated bandwidth, according to a strategy of Best Effort type.

(31) The transmission to the server of the acquired data can be done on a continuous flow basis, when transmission resources are available (resources guaranteed in the case of a virtual link.) This operation mode requires only the storage of data in a buffer.

(32) Alternatively, the acquired data are stored (after possibly being compressed) in a memory of the switch and are only transmitted to the server in the event of a transmission request from the latter.

(33) In this case, the transmission request of the server contains the virtual link ID (and where applicable, the IP address, the UDP port and the segment ID) for which the stored data are to be transferred.

(34) As a general rule, a transmission on a continuous flow basis will nonetheless be preferred in order not to compromise the memory resources of the switch.

(35) As in the prior art described in the introduction, to acquire data over a virtual link, the server will simply be able to request an acquisition from the first switch, or more generally request it from any switch traversed by this link. However, in the present case, given that it is not necessary to reserve physical ports dedicated to acquisition and to provide direct physical links with the server, it may in certain cases be possible to carry out an acquisition of data into several switches over this link, notably for test reasons.

(36) It is understood that, according to the subject matter disclosed herein, the function of data acquisition is decentralized into the various switches. The removal or the addition of a switch does not require any hardware reconfiguration but simply the updating of the switching tables in the switch in question and, where applicable, the software package of the remote server.