How did we get to the point that four civilians can pilot a craft into space, orbit the planet, and re-enter the atmosphere with only a matter of months to train for the journey?
SpaceX, and specifically the Inspiration4 mission, are an example of how the market forces of higher volumes of space launches and lower cost of space vehicles resulted in significantly more automation and sophistication in spacecraft.
New technologies like smaller, lower-cost communications satellites and reusable launch vehicles mean there can be more launches with a higher yield of payloads delivered to orbit. Those innovations have come about largely due to the entrance of private companies to the space launch services industry. With private industry comes the desire to reduce cost through, once again, reusable launch vehicles, but also smaller engineering teams, vertical integration, in-house component design, and more aggressive delivery schedules.
To achieve these goals, space companies are using computers that can make more automated decisions to control the launch vehicle than have ever been used in space technologies before. These controllers can now act on tens of thousands, hundreds of thousands, and, maybe soon, millions of input scenarios to make split second decisions that could only be made by humans in the craft or on the ground before.
The side-effect of all this decision-making power is the need for test methods that can simulate millions of scenarios for the computers. To ensure that the controllers always make the expected decision, they must be put into the scenarios in as real an environment as possible.
One way that design engineering teams are running these thousands, or millions of scenarios on their controllers is with digital modeling. The embedded software of a controller can be rendered in the digital realm and given simulated inputs to test the outcomes of the installed firmware. This method is called model-in-the-loop testing.
Model-in-the-loop testing can only go so far as testing the software, however. Imagine a life support control system receiving odd voltage levels that it would never expect to receive through the avionics communication bus because two cables that shook out of place are now affecting one another. It could even be that a power surge has happened elsewhere in the craft and there is now a fluctuation on the power rail or a complete disconnection on a line. The only way to simulate these electrical and physical scenarios is to hook up real hardware and make them happen in a safe, non-destructive manner. This type of test is called hardware-in-the-loop (HIL).
Hardware-in-the-loop testing allows engineers to create any set of single or multiple controllers, or line-replaceable units (LRUs) as they are called in much of the industry, to pass actual signals, or actual catastrophes, to the embedded software generated in the digital realm. In a May 14, 2021 tweet, Elon Musk responded to a question about end-to-end integrated avionics and software testing by saying that “hardware-in-the-loop testing is essential.”
This means that HIL systems are generally made up of these components:
Connectivity, switching, and signal conditioning: These systems often depend on the controller or system under test and can include any number of mass interconnects, cables, resistor networks, and more. These are also the components that technicians and test operators spend hundreds of hours adjusting, reconnecting, disconnecting, and reconfiguring to account for different controller configurations and in-flight scenarios.
Signal measurement and generation instrumentation: LRUs tend to have a standard array of signal types including general purpose digital ports, analog sensor input and output, and communications busses, while also often having unique signaling requirements. It’s common that small variations in instrumentation are required from one controller to the next even on the same vehicle.
Power supplies and load management: All controllers and subsystems have power needs, but, more importantly, must behave as expected when the power they require is affected by anomalies elsewhere in the vehicle. These tests systems need to include sophisticated power distribution, loading, and switching equipment to simulate these incidents.
Test management software: Each run of a full test script could include thousands, or tens of thousands of separate routines for the equipment and software packages in the test system. Test management software orchestrates all this instrumentation communication and model integration to ensure that tests are repeated exactly and executed completely on every test run. Ideally, this software can also log all test outcomes to a remotely accessible database, manage access and user data for engineers and operators, as well as tracking instrumentation health data like calibration dates, firmware versions, and more.
Digital modeling and simulation software: Perhaps the most critical component of an HIL test system are the real-time models of the other components, controllers, and subsystems that surround the LRU under test in the actual deployed system.
Modern LRUs are largely reconfigurable and defined by software thanks to advanced and affordable field-programmable gate array (FPGA), graphics processor (GPU), and sensor technologies. So, imagine the number of subroutines, signals, and unexpected scenarios each controller has and must account for in the test process to ensure it is ready for flight. Also, imagine changing test inputs and scenarios constantly as the firmware of the LRU is changing and new signals are required as a product of constant change throughout the vehicle.
Taking advantage of cutting-edge technology in controllers makes building test systems that can handle this pace of change difficult. Engineering teams that want to meet today’s fast-paced schedules, lower budgets, and rate of design iteration should be considering test systems that are simple to design and deploy, software-defined, modular, and maintainable.
Simple to design and deploy: Engineering teams that are designing controllers shouldn’t be spending most of their effort on configuring and deploying the test system used to validate their product. An HIL test system design approach based on signal-engineering using modular hardware and software subsystems enables a core design to be created and readily updated as requirements change, reducing risk while enabling early development of test programs. Additionally, choosing an HIL solution that includes significant documentation like well-defined signal paths, standardized system components, and step-by-step software startup instruction will save these teams hundreds or even thousands of hours.
Software-defined: There are several levels of programmability when it comes to modern test instrumentation. The minimum level of flexibility required is the ability to be controlled and to collect data by way of automated software commands. Instruments that give the user access to lower-level functions and instrument states to change the behavior of the instrument can allow engineers to solve even more complex measurement challenges. The ultimate in instrument programmability is allowing engineers building HIL systems access to the firmware of the test instruments to make fundamental changes that allow an instrument to act in a completely new way to test a new signal or technology. One way that modern instruments have achieved this level of customizability is by way of FPGAs on board the instruments.
Modular: As new requirements and signals are added to the collection of inputs and outputs an HIL system must accommodate, teams will often need to add new instrumentation, power supplies, loads, or signal conditioning to the system. To maintain budget, mobility, and schedule, these new capabilities must be easy to add to the system without adding significant size, power draw, and heat. Modular test system platforms abstract the power management, displays, and cooling systems of the instruments to minimize the changes a system must undergo to gain new capability. In the case of some modular platforms, adding a new signal type can be as easy as sliding a new module into a chassis, connecting it via standard cables, connectors, and pinouts, and installing a driver with little to no need for additional concern over size, power, or heat.
Maintainable: HIL systems that comprise commercial-off-the-shelf software and hardware components are easier to maintain in the long run as the maintenance of these components is generally handled by the vendor. That is especially true in the case that vendors offer long-term service and maintenance contracts. On top of that, modular systems reduce maintenance by allowing the engineering team to change and upgrade the system piece by piece. Replacing an end-of-life component could be handled with a single module and driver using software abstraction to avoid impact on test execution programs.
Avionics engineering teams should minimize the time they spend on test to accelerate the pace of innovation needed to reach the next era of space exploration. Investing in HIL test systems that are software-defined, modular, and simple to design and deploy will keep technology moving forward instead of miring engineering teams in tasks that are not their primary calling. Achieve an even faster pace of HIL test deployment by seeking the expertise of organizations that have deployed standardized test systems for LRUs across the industry with design tools that automate configuration and reduce lead times by months.
This article was written by Ben Robinson, Solutions Marketer; Aerospace, Defense and Government B.U.; NI (Austin, TX). For more information, visit here .