Applying MBSE and ML to missile safety subsystems

February 13, 2024

Brian Hetsko

CAES

With the relatively recent adoption of model-based system engineering (MBSE) and digital mission engineering in military acquisition programs, there is a unique opportunity for the safety and instrumentation industry and regulators to take advantage of the many benefits and shorten the change to qualification cycles. It can also be a chance for the industry to leverage newer technologies such as autonomous decision-making and machine learning, now that these tools are maturing.

Missile and space launch flight safety and instrumentation systems are complicated and highly regulated critical infrastructures. The typical instrumentation and safety subsystems consist of, at a minimum, data acquisition, flight termination system (FTS), telemetry encoding and transmission, and positional/navigation sensors. These subsystems are all tightly integrated and interdependent; however, the requirements and regulations associated with each are highly independent in their specification. Therefore, when platform developers and integrators are determining their approach to flight safety, considerations for all components must be paid with respect to the nuances of each and how they might relate to one another.

In a typical product development environment this doesn’t seem like anything out of the ordinary: Make the change, verify it, and deploy. But as is the case with most military systems and especially the range safety community, the validation, verification, and – ultimately – qualification processes are dramatically more time-consuming and expensive. Of course there’s a good reason – these regulations are in place to maximize reliability and predictability of the platforms, such as missiles and rockets being flown or launched, and the risk and safety posture associated with their use.

Model-based system engineering (MBSE) provides an abstraction of the specification and design features from the typical document-driven methods of the past to those of models built in one of many software tools. The U.S. Department of Defense (DoD) and other industries have been making slow strides towards MBSE for years, but only recently have programs and new weapons system developments mandated an MBSE approach from the start.

While software or computer-aided design has been ongoing for decades, the primary difference now is how those independent designs can be linked with the various types of system models. There are functional, physical, and analytical models, and activity diagrams, to name a few; all of which are useful in this context. Now, as a system or subsystem is being designed there are features, behaviors, and interactions which can be simulated, through combinations of electronic, mechanical, environmental, and software models. In fact, MBSE is ­presenting itself in all industries as the next evolution of the system engineering life cycle.

Establishment of an integrated framework for modeling complex component, subsystem, and system interactions across airborne systems and ground systems enables heightened coordination between the engineering teams. It also enables designers to integrate platforms, operating environments, communications (both RF and optical), and sensors including radar or EO/IR [electro-optical/infrared] for more effective and efficient development.

Since the 1950s, the specifications for range safety have been established by the Range Commanders Council (RCC) and its respective subgroups and standards body, Inter-Range Instrumentation Group (IRIG). Collectively these organizations define and enforce all of the standards for such metrics as environmental survivability, communications, protocols, and security associated with DoD and NASA ranges.

As with most military and space-related products and systems, strict traceability is maintained from concept through deployment and disposal following a traditionally stage-gated waterfall life cycle. The introduction of models and agile development has changed how the entire acquisition process can answer the needs of the warfighter. With increasingly high resolution and reliability models, the confidence that the designs and tests fully satisfy requirements is approaching completeness. If the regulations are considered as the prevailing requirements for any design, then the challenging process of tailoring can become clearer as the linkages of the requirements to the various subsystem models allow for impacts to be analyzed much earlier in the life cycle, ultimately accelerating acceptance.

Application to flight termination

The traditional method of flight termination, conducted by a person monitoring real-time telemetry, is being phased out of some use cases with the advent of autonomous flight termination. Autonomous flight termination units (AFTUs) receive some subset of the total telemetry payload and make a determination based on a rather prescriptive set of rules. The modalities of the rules are limited at this time but are constantly evolving. The parameters and bounds of these rules are established for each particular range and platform and once defined cannot easily adapt to changes in subsystem function or external stimulus without extensive verification. This is just one of the reasons that autonomous flight termination has been largely limited to space launch or ballistic flight; both are highly predictable flight profiles and therefore the modalities are equally deterministic.

Given that the primary, and minimum, required data for autonomous flight termination decision is related to position, vehicles such as air-to-air and air-to-ground missiles have less predictable behaviors, higher velocities, dynamic target acquisition, and have greater potential for damage or injury; other, larger-sized vehicles have more predictable failure modes and effects.

Using a model-based approach with added machine learning (ML), the possibility exists to more dynamically generate and validate the rule parameters, known as mission data load (MDL) for autonomous flight termination. The current limiting factor to adoption of autonomous flight termination by tactical platforms is the lack of the ability to rapidly and reliably adapt the parameters for different test conditions and locations.

For instance, different aircraft may carry the same weapon, so the profiles and conditions for termination are going to be very different. Using models for each platform and the associated behaviors, interfaces, and environments, a resulting behavior model can be created which can be validated through a series of simulations (e.g., Monte Carlo) taking the results and feeding back into the model generation system ­creating an adaptive cycle for high-reliability flight safety. Reinforcement learning (RL) is the likely branch of ML to be applied in this case in that it is a trial-and-error-based approach where the agent responds to a stimulus change and learns via responses to “reward” or “penalty” and converging on statistically ideal conditions for success.

For instance, a system model for a generic flight instrumentation and safety system is shown in Figure 1. In this model, the primary subsystems and their respective interactions and interfaces are all functioning as expected. The data link has an active bi­directional connection to the host platform; the PNT [position, navigation, and timing] subsystem has positive lock; the data acquisition system is receiving and processing data from dozens of sensors and telemetering it for monitoring; and the flight termination subsystem, assuming it is autonomous, is in its standard mode of receipt of data from other subsystems.

[Figure 1 ǀ Flight instrumentation system model where primary subsystems are functioning as expected.]

Within the modeling system, each subsystem can have its functions and behaviors modified very slightly and independently and the results – with respect to each interface – are then shared across the enterprise to understand the impacts to the other subsystems. This setup enables far more permutations than would be practical in a verification testing scenario.

For example, if the PNT system goes into a state where the timing or reliability are compromised, how that is handled by each connected system can be determined holistically, not only pairwise. In this case, the AFTU would detect an anomaly from a critical component, compare that to the required redundant path for decisions, and make a determination as to the PNT being unreliable or potentially in a failure mode and terminate the flight. Since the entire infrastructure is modeled in software, small adjustments can be made thousands of times to identify the permutations and limits which eventually converge on the final MDL parameters.

Not only do design changes to any subsystem affect the encapsulated system of systems, but also included in the sample model are the governing regulatory specifications. As shown, each basically has its own, so any change to those specifications can potentially trigger a platform-level validation and verification to ensure conformance. Often these validation and verification activities can be satisfied by some level of analysis, typically statistical or heuristic.

Although edge conditions and negative testing are often either overlooked or dismissed due to cost, they can now be built into MBSE and ML models. Prior to any ratification, the impacts of every change can be understood relative to all of the subsystem models to which it is attached and the downstream effects. As most flight-safety and instrumentation subsystems are increasingly software- or firmware-defined, changes can now be deployed without having to invalidate any hardware configuration or qualification further supporting the tactical adoption. While MBSE is able to help with development of mission rules, ML will ultimately propel the advancement of instrumentation and safety system development through simulation-driven verification traceable to the regulatory requirements.

Brian Hetsko has more than 20 years of aerospace and defense research and development experience in the areas of communications, signal processing, intelligence, surveillance, and reconnaissance. He is currently the Director of Engineering at CAES in Lancaster, Pennsylvania.

CAES • https://caes.com/