Traditionally, testing is a manual, labour-intensive process and because of staff lock-downs and social-distancing rules during COVID-19, production ground to a halt for many spacecraft OEMs.
Much of the equipment used to test satellite avionics can be commanded remotely and test procedures can be created, automated and controlled by the same engineers from their homes. This allows manufacturers to continue operating and maintain production by limiting the number of staff physically required at the factory, generate income, sustain employment, deliver products to meet their customers' schedules and fulfill contractual, time-to-market needs.
Figure 1 : Remote control of test equipment
For many satellite OEMs, the highly-contagious coronavirus pandemic identified major shortcomings with their existing manufacturing approach and test equipment, brutally exposing limitations. Remote testing will allow manufacturers to prepare and adapt for the future, and staff lockdowns during COVID-19 highlighted the value of social-distanced testing for many of Spacechips' clients.
Testing satellite avionics occurs throughout all stages of spacecraft development: from characterizing the performance of individual analog parts, digital logic, RF circuits and antennas during initial component selection of the system architecture phase, or de-risking these at a cyclotron, to verifying the functionality of hardware demonstrators and validating proof-of-concepts at the prototyping (EM) phase. This is followed by measuring the performance of complete payload sub-systems and then entire spacecraft validation in a representative environment using thermal-vacuum chambers during the qualification (EQM) stage.
Prior to lift-off, final integration checks are typically performed at the launch site and throughout operation, regular on-orbit checks of the transmission links are made to monitor and confirm quality of service (QoS). Each of the above development stages present unique test and measurement challenges for manufacturers of satellites.
Figure 2 : A comparison of interface latencies and bandwidths
Typically, the characterization of individual parts or EM sub-system testing is a manual process where specific tests are created, before elaborate test benches and/or equipment racks are built, controlled using vendor-supplied firmware such as Vector Signal Explorer, or proprietary software coded in-house at huge expense and effort, to meet production test, analyses and reporting needs.
Some test equipment allow the manual measurements created during prototyping to be recorded which begs the question, why can't this sequence of tests simply be repeated for qualification and production to reduce costs and meet operators' time-to-market needs?
In 1975, the IEEE standardized a bus developed by Hewlett Packard, originally called HPIB (Hewlett Packard Interface Bus), later changed to GPIB (General Purpose Instrument Bus), defining the mechanical, electrical and handshaking aspects of the standard. This was also known as IEEE 488.1, formally updated to IEEE 488.2 in 1992 to include protocol and data-formatting properties, but not which features or commands should be implemented for particular test equipment.
In 1990, the SCPI (Standard Commands for Programmable Instruments) Consortium released an additional layer to IEEE 488.2 with the view to unifying the command sets used by different instruments and manufacturers. SCPI promotes consistency and commands are ASCII strings sent over a physical layer which can perform set, query or both types of operations.
Figure 3 : A remote control, virtual front panel
As an example of its syntax, the command to measure a d.c. voltage would be,
or, to set an RS-232 interface to 2400 bits/s is:
Commands can be abbreviated or concatenated and the complete standard can be freely downloaded. Figure 1 illustrates the different software and hardware layers involved to remotely control and automate test equipment. This instrument is at the bottom and your application is at the top.
Out of motivation to unify the software interface, the VXIplug&play Systems Alliance introduced the Virtual Instrument Software Architecture (VISA) layer to shield your application from the specifics of the physical communication. VISA implementations come from different vendors in a variety of languages such as Python, MATLAB®, C#, LabVIEW™ or ANSI-C, but they all must abide to the same standard which includes functions on opening and closing a remote connection to an instrument and reading and writing strings from or to test equipment respectively.
Figure 4 : A digital satellite transponder [Source: OOTWD]
Free, open-source languages such as Python are increasingly being used by a more cost-conscious satellite industry and the selection of an interface is primarily based on its bandwidth and latency with respect to the measurement need as shown in Figure 2, as well as factors such as heritage, expertise and time-to-market.
In addition to automation, test equipment can be manually controlled from a distance using a Remote Desktop, VNC viewer or a web browser to facilitate cyclotron, qualification, production and launch-site measurements. SCPI commands can be sent to/from instruments, or virtual front panels can be displayed on a local device and controlled interactively as shown in Figure 3. Measurement results are uploaded to secure on-line cloud storage and using your PC, phone or tablet, these can be accessed for analyses and reporting.
Figure 5 : The R&S SMW200A Vector Signal Generator [Source: OOTWD]
Figure 4 shows a single channel of a digital transponder typically used within an Earth-Observation (EO) or a telecommunication satellite: the first tests are a series of single-tone measurements at different frequencies to understand in-band SNR, harmonic and spurious performance. CW characterisation allows OEMs to simultaneously differentiate between device-level artefacts and system issues, e.g., an ADC interleaving spur vs. noise coupling from the routing of the sampling clock, power supply or poor grounding.
Once the single-tone performance of the transponder has been understood, its linearity and wideband operation can be characterized using more representative stimuli such as multi-tone or noise-power ratio carriers to provide a measure of intermodulation distortion. The complete payload is then tested using representative stimuli such as modulated carriers to verify operational performance.
Figure 6 : The F&S SMW200A's built-in SCPI command macro recorder
All of the RF input types can be supplied by the R&S SMW200A Vector Signal Generator: this has the ability to automatically generate and record the equivalent SCPI commands of all tests manually created during initial prototyping, which can then be replayed automatically for qualification and production to reduce costs and meet operators' time-to-market needs. The same sequence of measurements can be run remotely during lock-downs respecting social distancing. Templates are provided for directly generating executable code for various platforms, e.g. MATLAB® or ANSI-C, and the R&S SMW200A supports the IEEE-488.2, LAN, USB and RS-232 interfaces.
At the output of the transponder, the R&S ZNL can automatically measure performance combining a two-port, bi-directional VNA with spectrum analyzer, demodulation and a power-meter controlled using its GPIB and LAN interfaces. Real-time spectrogram, Distance-to-Fault (DTF) and time-domain analyses options can also be added to the instrument.
To reduce the cost-to-market, some spacecraft manufacturers are starting to consider testing as a service (TaaS) to save on the capital expenditure, as they do not have to maintain the equipment infrastructure and only pay for the measurement services they actually use. This allows OEMs to pool all or a part of their instruments, making them accessible companywide from any location. Obviously the device-under-test needs to be physically connected to the setup as illustrated below. TaaS and cloud-based measurement equipment are allowing OEMs who have been affected financially by COVID-19 to significantly reduce CAPEX costs, making instruments accessible companywide from anywhere. To complement testing, Cloud4Testing is a subscription service which allows for remote analyses of measurement data. If you would like to explore and exploit the cost benefits of cloud-based TaaS, please contact Rajan Bedi.
Figure 7 : The R&S SMW200A's built-in SCPI code generator for MATLAB® [Source: R&S]
Staff lock-downs and social distancing during COVID-19 disrupted global satellite production, much of it intended for export around the world. Remote testing has allowed some manufacturers to remain productive and operational while respecting social-distancing rules. For OEMs delivering to clients with strict time-to-market needs, this approach has enabled them to deliver on-time, generate income and avoid late-payment penalties. Furthermore, remote testing has helped companies to maintain existing staffing levels avoiding the need to avail of government bailout assistance.
Manufacturers who have been disrupted by COVID-19 are planning to avoid future production stops, upgrading their test capabilities to become more automated, controlled by the same engineers from their homes if required. TaaS and remote testing are sustainable forms of testing helping space companies become more green.
Dr. Rajan Bedi is the CEO and founder of Spacechips, a UK SME disrupting the global space industry with its award-winning, Satellite-Communication Products, Design-Consultancy, Technical-Marketing, Business-Intelligence and Training Services. Spacechips successfully showcases and exports British engineering excellence by selling its products and services to more than 25 countries. Spacechips won New Company of 2017 and Rajan's inventions won High-Reliability Product of 2016, 2017 and 2018. Rajan is also President of Spacechips LLC and author of Out-of-this-World Design, the only blog dedicated to Space Electronics. Rajan was previously invited to teach at Oxford University and in 2020 was shortlisted for Great British Entrepreneur of the Year.
Figure 8 : The R&S ZNL Vector Network Analyser [Source: OOTWD] Figure 9: A test & measurement equipment cloud being accessed by two users [Source: R&S]