With edge computing becoming more prevalent in military and defence, network speed becomes invaluable. Here, Martin Frederiksen, managing director of embedded military technology specialist Recab UK, highlights the importance of deterministic Ethernet in front line operations.
In military and defence applications, speed is crucial. Whether that is the response time of deployed soldiers or the speed at which information is communicated from the field to outposts or command centres.
Increasingly, embedded edge systems are used to collect, analyse and communicate data from the field in real-time — driving a need for deterministic network protocols.
Whether they are onboard military drones used for reconnaissance or on naval warships to communicate their position, embedded computing systems are widely used in the military sector.
This is only set to continue, as growth predictions from analyst firm MarketsAndMarkets anticipate the global military embedded systems market size to be valued at $18.4 billion by 2025, growing at a compound annual growth rate (CAGR) of 6.4%.
The growth is impressive but not without its challenges. Military edge embedded systems must not only meet strict regulatory standards, but they must also be able to exceed demanding operational expectations.
Distributed military computing must be able to offer low-latency, high-availability, interoperability between networked devices and high-bandwidth.
Many applications, such as radar, electronic warfare, signals intelligence or weapon control systems, have extremely tight latency constraints and demand accelerated edge computing via field-programmable gate array (FPGA) devices. In most cases, networked applications need to be able to synchronise within a nanosecond time range.
Through Recab’s extensive work with military and defence system developers, we have noticed a clear trend towards Ethernet as the network protocol of choice due to a relatively low cost and ubiquitous nature.
However, Ethernet is generally non-deterministic — something that makes it typically reliable but impractical for mission-critical, dynamic systems.
Deterministic Ethernet
There are protocols that can be used to support Ethernet in meeting mission-critical system demands. As an example, to benefit from zero-delay recovery time and no-frame loss in the event of network failure, the sector is adopting Ethernet-based protocols like high-availability seamless redundancy (HSR) and parallel redundancy protocol (PRP), both outlined in IEC 62439-3.
HSR provides redundancy by sending packets in both directions through a ring network. A simple HSR network consists in doubly attached bridging nodes, each having two Ethernet ports.
Both ports send the same data frame so that, in a fault-free scenario, nodes receive two identical frames. This means that even if the fibreoptic is broken, no frame loss is ensured and the communication among all network nodes continues.
PRP, on the other hand, implements redundancy in the nodes rather than in the network. Dual attached nodes (DANs) are connected to two independent and standard Ethernet networks (LAN A and LAN B) and send the same frames over both networks. The PRP operative ensures the receipt of all the information, even if one network fails.
For standardised deterministic Ethernet networking, the best option is time-sensitive networking (TSN).
TSN is the new generation Ethernet that provides determinism to enforce advanced quality-of-service policies.
It supports in the same network hard real-time, reserved and best-effort traffic. The seamless redundancy at frame level is supported by the IEEE 802.1CB TSN standard.
Simplifying connectivity
With the continued move to real-time, high-bandwidth and open networks of fixed and dynamic embedded systems, the process of determining a scalable system naturally becomes more complex.
As the use of dynamic, edge-embedded systems in front line settings continues to increase, more military OEMs will experience this mounting complexity when establishing networks.
Ensuring that data can be shared as efficiently and quickly as possible, in an environment where speed is of the essence, is imperative — but it does not need to be so complicated that it slows down project development.
