User:Graham.Fountain
Work: Senior Engineer 3 - Technical Specialist in the Networks Group of the Research and Technology Dept., of a large multinational aerospace co.
Other: Chairman BSI committee ACE 6/-/9: Aerospace - Digital data buses, 1992 to Aug 2013.
Interests:
- Avionic data networks and data buses:
- Integrated Modular Avionics
- Guaranteed reliable and secure (i.e. tolerant of faults, and malicious actions), real-time data transfers over packet switched networks, for safety-critical and mission critical applications. Moreover, allowing these guaranteed real-time transfers between the standard Ethernet network interface units that are integrated into almost all the likely equipments, i.e. done properly, not like AFDX or TTEthernet do it. However, as control of transmissions from these standard network interfaces cannot be reliable, the network has to limit what it will transport (in which case the interfaces only have to control their transmissions to avoid losses from this control) so that there can be no congestion within the network, i.e. there are no losses whatever the sources transmit within the limits the network applies:
- Network congestion prevention - the ultimate level of congestion control: for real-time data that must be proved to be transported safely, an ounce of prevention is worth a pound of management and a ton of avoidance.
- In regard to hard real-time and soft real-time: “Hard real-time is hard, soft real-time is even harder.” (E. Douglas Jensen)
- The difference between hard and firm real-time, at least in terms of data transport over imperfectly reliable media, merely represents the difference between theory and practise - “In theory, theory and practice are the same. In practice, they are not.” (Attributed to Albert Einstein) So, while distributed real-time systems like IMA may, in theory, be hard real-time, in practise they must allow for some level of loss, and are, necessarily, firm real-time.
- However, what does not appear to be well understood, or is at least not well discussed, in regard to real-time data transport (unlike in real-time computing), is that delivering hard or firm real-time data after its deadline is the same as failing to deliver it at all. It may even be argued that late delivery is worse, because the data is valueless, but still consumes resources - see Time-utility function. Hence, sufficiently delaying a real-time data transfer has at least as great an impact as preventing or corrupting it. So, in the context of secure, real-time, safety/mission critical data transport, a real-time transport protocol has to provide a means of proving timely delivery, as well as providing proof of reliable delivery.
- Network congestion prevention - the ultimate level of congestion control: for real-time data that must be proved to be transported safely, an ounce of prevention is worth a pound of management and a ton of avoidance.
- And the only way to actually prove that (either or) both reliability and timeliness requirements for delivery will be met (even firm real-time ones) is to guarantee that the real-time traffic is fully protected from congestion, which may not be easy, but has to be done. It may also go against the grain of IP, in requiring complex functionality in the network. But where provably reliable and secure, real-time performance is required, there is no choice.
- The Deterministic Ethernet Fault Tolerant Network (DEFTNet) concept.
- DEFTNet is a patented (by BAE SYSTEMS) real-time data transport (Layer 2) concept that allows the use of standard IEEE 802.3 Ethernet interfaces and thus the interconnection of commercial off-the-shelf (COTS) components, such as single board computers (SBCs), and thus helps to minimize the ownership costs of systems such as avionic mission systems through the leveraging of these COTS components. This includes moving the level of upgrade and obsolecence managment away from the level of simple electronic components to the board level.
- DEFTNet achieves reliable, timely delivery of Ethernet data frames by applying traffic policing to the real-time data connections in the network, i.e. logically at the inputs to the switches. This allows the maximum impact of the connections routed through any component in the network, e.g. the multiplexing buffer associated with a switch output, to be calculated. If this impact is within the capacity of the component, e.g. the maximum usage of the buffer is less than its maximum capacity, there will be no congestion of that component and no consequent loss of data. Also, the maximum delay from that component, e.g. the time taken to empty the buffer from its maximum fill level, can be calculated. The component delays for the known path of the real-time connection can then be summed and compared with the deadline for the data. This requires that components operate losslessly while within their capacity, e.g. the multiplexing queues must be managed by tail-drop and may not use RED or WRED, etc.
- The losses of real-time data will then be limited to those from the physical layer, e.g. bit error rates (BERs), which can, at least, have determinable levels, and no data will be delivered late.
- The DEFTNet concept proposes the use of IEEE802.1Q VLANs to identify individual realtime connections. The 12-bit VLAN Id field thus limits the number of real-time connections to 4094 (2 values are generally reserved), However this is purely a local limit, i.e. at a switch, potentially at a switch input, as VLAN Id can be reused as long as there is no conflict. These real time VLAN Virtual Connections (VCs) can also be isolated from other, e.g. best efforts traffic, through the use of aspects of IEEE 802.1Q CoS. If only the real-time data is allowed to use the highest priority and the associated queues are serviced with simple priority over all others, then the effects of best efforts traffic can be factored into the calculations of capacity and delay. However, this requires that the network imposes priority, i.e. only that traffic identified as real-time, to which traffic policing is applied, can be allowed to use the highest priority. Any other traffic identified by its source as using the highest class must be demoted. This has to be applied by the network, e.g. by the switch inputs based on the VLAN Ids reserved for realtime traffic at the input.
- Because the VLAN Ids used for real-time traffic must be associated with specific switch inputs and outputs, to define their routes so that which resources they affect is known, traffic for a connection is only allowed to have a specific source and is only routed to a specific destination or destinations. Hence, the confidentiality and integrity of real-time data is maintained in transport. The real-time reliability and timeliness provided is assumed to meet availability requirements for secure data.
- Legacy equipment that cannot be made to support VLANs will require switches to use, e.g. deep packet inspection, to identify real-time connections and apply VLAN Ids appropriately.
- While the features required by DEFTNet may be relatively rare in COTS Ethernet switches, they are available. Hence, it is at least possible to built a DEFTNet network entierly from COTS components. While this equipment may not meet many of the requirements for use in avionic systems, e.g. ruggedization and certification, it has very significant implications for the costs of building such systems and in their support, e.g. in ground based rigs, etc.
- Faults and failures in the network, e.g. switches and physical layer links can be tolerated through the use of redundant networks, e.g. 2 or more identical networks with their equivalent switches isolated from one another. This requires the connected components to use 2 or more network interfaces, transmit identical copies of all data through these, and consolidate multiple copies of a data instance that are received. However, should any component and some combination of components in the network fail, the data will still be delivered reliably and in a timely manner.
- The DEFTNet concept may seem excessively prescriptive in many contexts. However, for an understanding of this, its complexity and the advantages it provides should be compared and contrasted with TTE and AFDX and their use of proprietary network interfaces and switches. These protocols have already found niche applications in avionic and space borne systems, even given that they do not support standard IEEE interfaces or the full range of data rates provided by Ethernet.
- The Deterministic Ethernet Fault Tolerant Network (DEFTNet) concept.
- The leaky bucket and the token bucket algorithms - they're the same thing really.
- The generic cell rate algorithm (GCRA).
- OpenFlow (versions 1.3.0 and later).
- The leaky bucket and the token bucket algorithms - they're the same thing really.
- Legacy buses and networks:
- MIL-STD-1553B
- EN 3910 and EFABus - formerly STANAG 3910
- The Asynchronous Transfer Mode
- Liner Token Passing Bus - AS 4074.
- Related issues
- TEMPEST testing
- The Triumph TR7 Sprint
- 59-61 cars built in 1977 as homologation specials for the Group-4, 16-valve TR7 rally car for the 1978 season: The 16-valve rally car had been homologated for group-4 in October 1975 as a modification of the Group-3, 8-valve that was homologated earlier in 1975. This used the "100-off" rule in the FIA's appendix J rules. That rule allowed certain modifications, like multi-valve heads, gearboxes, overdrives, and clutches, etc., on production of 100 of the part. It did not require 100 cars to be modified. However the rule was deleted in 1976, with parts and cars homologated under previous rules allowed to continue to be rallied until the end of 1977. This meant that if the 16-valve TR7 was to be used into 1978, until the TR8/TR7V8 was itself homologated, the 16-valve head had to be re-homologated on production (the other affected parts were either replaced or homologated for Group-3, and therefore automatically available to Group-4 cars). While the FIA's requirement for homologating a modification on production doesn't seem to be published, several other modified cars are reported to have been homologated on production of 50 - Vauxhall HSR and Porsche 924, and possibly 1978 spec Escort RS1800, homologated into group 4 as the 1975 cc Escort RS (FIA number 650). The 16-valve head was given approval for use on the TR7 in group 4 once again in February 1978, and a set of 6 photos in the archives of the British Motor Museum identify the TR7 Sprint in this process.
- On the parallel homologation of the TR8, while there were only about 150 FHC TR8s built when it was approved on 1 April 1978, another 250 or so were built in the following months after the move of TR7/8 production from Speke to Canley. This seems to have been under what Neil Eason-Gibson once described to me as a promise to manufacture. This process is described in the article "Chevette 2300 HS-what went wrong" in Autosport magazine, 27 April 1978. That there were, at most, 400 FHC TR8s built (possibly including TR7s converted to TR8s by BL), shows that they, like the TR7 Sprints, were only ever built as homologation specials. The other, several thpousand, TR8s, mostly US and a few UK spec., were all DHC convertibles.
This user's motto is:
- Why put off till tomorrow what you can put off till next week?
This user lives too close to Blackpool for comfort.
This user lives too far from York to be happy.
- "It's a great place to live, but I wouldn't want to visit there."
- Of the one-way system - "Well, if I was driving there (York central library), I wouldn't have started from here (Parliament St)."
- From a bemused American tourist "Why the hell do they call the streets 'gates', the gates 'bars', and the bars 'pubs'?"