90 Product focus | Transponders form a bottleneck in the transponder’s functioning, enabling far more rapid movement and storage of data. With device manufacturers increasingly leveraging SoCs, next-generation transponder designs may run on multicore processors, probably still in SoC formats but allowing the separation of cores to allocate functions between them. For instance, one core could run an ACAS algorithm, another could run ADS-B functions, one more could perform inter-protocol translations and another could run encryption if needed; such separation could be key for proving design and operational assurance levels to aviation authorities one day (by preventing crosstalk, lag or other issues caused by relying on a single core). Also increasingly critical are integrations of high-quality GNSS receivers and pressure altitude sensors into transponders, both of which continue to miniaturise to the benefit of manufacturers. Choosing these and all other components must be done with absolute certainty, as once a design is certified, it cannot be significantly changed, lest the developer risk losing their certification. This means not changing a component or any aspect of the hardware configuration, so ensuring secure supply chains of certifiable components is a vital part of modern transponder development. From a software perspective, it can merit a bare-metal engineering approach, by which the lowest levels of algorithms – down to programming languages and toolsets are controlled in-house – so the transponder software engineers are not beholden to third-party tools (and, more seriously, layering-in third-party programming libraries or similar inputs can interfere with certification if they themselves are not certified). Additionally worth noting is the growing integration of cryptography modules into Mode 5 IFF transponders. In the US, this means using KIV encryption modules certified exclusively by the National Security Agency (NSA) (and no UAV transponder companies are authorised to produce KIVs at present), so that encrypted transmissions can be received by the transponder, and then processed, validated and decrypted by the KIV, and the KIV can send data back to the transponder for it to transmit. This entails a very narrow timing window, meriting extremely tight integration between the two parts, and the standards for doing so come with a very high level of requirements, covering not only timing but validity, bandwidth and other parameters that the transponder manufacturer must mind. Engineering process Developing a new transponder, be it to meet a new standard or fit a customer’s spec, starts with defining system requirements, such that concept transponder architectures can be tuned with the right components, firmware, measurements and so on. Transponder engineers therefore pay close attention to the letter of the law from regulatory standards, as software and parts tailored to do anything outside of certification requirements may wind up interfering with other communication links or causing faults with their own timing requirements. Once this onerous planning process is completed, design simulations can be run to define the schematics and engineering tolerances of the first prototype’s hardware, taking account in such modelling for how the transponder will perform electrically, electromagnetically, and thermally within the possibly cramped and harsh environment internal to a UAV. As with any avionics, care can also be taken in CAD and FEA simulations to check that the board and enclosure layouts tolerate shock, vibration and outside sources of EMI, as well as certification requirements. Software development can be run in tandem and this typically moves faster than for hardware. Transponder software engineers increasingly use development boards based on past product iterations, as components reasonably similar to that on the expected prototype provide an adequate environment for programming ADS-B or related software to new standards. Such software will routinely be run in simulations to affirm the future transponder’s ability to understand received signals and respond appropriately with the correct ADS-B information. Then, parts can be surface-mounted on board assemblies to build prototypes, with several iterations often taking place with significant hardware and software testing to define redesigns of system architectures and the contents of firmware patches. As discussed, a certified product cannot be significantly changed once released, so any mistakes cannot be patched out post-release, as they are in many other products. August/September 2024 | Uncrewed Systems Technology Transponder development takes considerable engineering and iteration of prototypes to optimise hardware architectures and firmware updates (Image courtesy of Aerobits)
RkJQdWJsaXNoZXIy MjI2Mzk4