Today’s battlefield is evolving quickly to keep up with adversaries and new threats. As such, the systems that our warfighters utilize need to constantly adapt and improve in order to remain competitive. With this progress, it becomes critical to close the concurrency gap between military platforms and the devices used for training.
As warfighters train, live systems are updated with new software and hardware. Inevitably, there is a capability gap between the real-world platform and the simulator. This gap in concurrency hinders effectiveness of a training tool just because it doesn’t accurately reflect what the student will find when he or she enters into the actual platform.
This then begs the question how one can shorten, or even eliminate, any development lag between onboard systems and their inclusion in simulation training applications.
To find out, we recently talked with Nick Scarnato, the Director of Strategic Marketing, Integrated Solutions for Collins Aerospace, and a 40-year industry veteran, for his thoughts on what causes these time delays and, in his experience, what approaches have been effective in developing a concurrent simulator system.
Here is what he had to say:
Modern Military Training (MMT) Editors: What are the main reasons for a concurrency gap and the delays between the aircraft and the simulator?
Nick Scarnato: Oftentimes, in order to implement avionics software on a training device, that software needs to be retargeted or rehosted from the real-world version for it to run on a training device.
Additionally, you add “training hooks”, which allow the avionics software to operate within a training device. An example of a training hook is when you pause the simulation, or “freeze” as it’s known in virtual simulation. And while you’d never want to do that on an aircraft in flight, we do that in simulation all the time.
Changes like this though take time to implement, and our customers can’t afford the delays between when software is implemented in the real-world aircraft and when its training-ready form is retargeted and rehosted in the simulator platform.
The same goes on the hardware side as well. If you’re going to add a new panel, new switches, or any new interface in the cockpit of an aircraft, that same modification needs to be quickly made in the simulator as well. That too, leads to a concurrency gap and might lead to negative training when trainees get accustomed to one hardware layout in the training platform and then are faced with a different layout in the actual platform.
MMT Editors: What are some of the best practices that you’ve seen in solving the concurrency challenges?
Scarnato: It’s important to develop the training system earlier in the process so, as you’re developing the system, you’re also bringing your training solution along, in a lockstep fashion with the real-world platform. In doing this, you can deploy not only the software, but also a fully concurrent simulator at the same time.
While you may think that might increase your costs early on, it pays dividends by the end of the development process. Now, you don’t have a large cost spike at the end when you have to put together a training device and a mismatch in concurrency that you have to deal with since they were developed separately.
Part of that effort could be building training capabilities like “training hooks” into the software of not only the training program but that of the actual platform as well, and in fact, we have delivered solutions like that to customers. And while you’d never use those functions while operating the aircraft, there is a match in software between the two domains, so you’re shortening the time it takes to adapt the software for the training solution.
What also significantly improves concurrency is installing the same equipment in the simulator that you find on the real world platform. For example, if you have a mission computer onboard the platform, use that same mission computer in the simulator. Is it going to cost more? Yes, but it’s the same operating system, it’s the same physical hardware and software and the same zero-delta latency that you see in the real world.
MMT Editors: When you talk to customers, what are their principle concerns and questions about concurrency?
Scarnato: Our customers clearly desire a 100 percent concurrent simulator and zero-delta latency performance. They are increasing their demand for that, and when you have those, you have a matching environment, which leads to increased realism in training, and ultimately, more effective training, and that’s what customers desire.
And as we move more towards training for multi-domain operations and increased interoperability, we’re seeing more and more conversations on this topic.