We have heard a lot of discussions over the past few years about emerging technologies and how they are affecting the delivery of training based upon virtual and mixed reality. There has also been a lot of discussion about the significant changes coming with regard to legislation which will allow these devices to have greater use within the training curriculum.
But what hasn't received much attention is the prospect of a move to cloud computing platforms for FSTDs. Apart from a presentation at the 2023 FSEMC by CAE¹ we’ve not seen much discussion of this, but one thing we know for sure is that the TDMs are looking at this, if there are any that aren't they certainly should be. We thought we would take a brief look at this and the implications.
What is cloud computing and how is it proposed to be used?
We used a cloud based AI tool (Microsoft co-pilot) to tell us what it is, the answer we got was “Cloud computing is the on-demand delivery of computing services like servers, storage, databases, networking, and software over the internet. It enables flexible, scalable, and cost-effective access to resources, supporting everything from personal data storage to complex business applications and advanced technologies like AI”.
In the world of FSTDs the ultimate goal would be to eliminate the physical individual computers, virtualise the models and run them across the internet in the cloud. So your FSTDs would have no host computer, just a gateway linking the internet to the linkage.
So what is virtualisation?
This is key to running multiple FSTDs on the same platform. The FSTD is created as a virtual machine with its own applications and operating systems acting as an independent machine even though it shares the same physical resources as the other FSTDs running on the platform. To give you a real example. SIM OPS took an old Mechtronix-built FTD with multiple Microsoft XP-based PCs with QNX real time host, virtualised all of the PCs, including the visual IG, and ran them on a local server. All the previous computer loads were untouched, we didn’t even have to re-compile them, running on the same server. We ran the QTGs before and after and they matched. Our exercise was undertaken to alleviate the obsolescence issue but it shows how virtualisation works. Whilst we only had the one FTD’s computers virtualised on the server, with sufficient hardware we could have had two or more.
What are the immediate prospects?
The CAE presentation at the FSEMC laid out a very sensible, and workable, roadmap.
First. Use the concept on what the CAE presentation termed as Entry Level Devices (ELDs).
Second. Running a number of FSTDs from a local, on premises server across an intranet.
Lastly. Full blown cloud computing where the FSTD loads are ….. well who knows, just about anywhere in the world or even in space!
We would actually argue that step one is with us now. Most ATOs deliver their ground school tuition using CBTs running across the internet. As for the second phase we’ve been to training centres where all the lower level devices, including flat panel trainers, were running on a central server.
For a complete cloud based solution, why not? There are of course some aspects more difficult than others, for example it is hard to imagine controls and motion computers being virtualised and run in the cloud in the immediate future because of the high frequency at which they run.. On the other hand, we’re seeing complex, fast-moving video games nowadays entirely cloud-based, so we may not be so far from a cloud-based IG. So overall it just comes down to bandwidth and latency.
There is also the question of the reliability of the internet, this cannot at the moment be taken for granted everywhere in the world.
What are the advantages of the cloud-based approach?
For the TDMs the advantages are clear to see, this is the logical conclusion of the inextricable journey of product loads (see our blog “Product loads - the good the bad and the ugly”). Oh, and as a happy consequence it will give them complete control of the devices lifecycle and a device life long licensing income.
For the trainers and trainees, if implemented well, it will mean consistency of training across all devices, including those in other training centres running the same way.
For maintainers, again if implemented well, it should mean easier maintenance. Less hardware means fewer failures. Then updating of databases becomes a single operation, by them or by the TDM.
Are there disadvantages?
Well the first thought that comes to mind is what about when/if you want to sell a device. On one level a fully cloud based solution may make an FSTD easier to move, for a start there will be less wiring and cabinets. Also once in the new location it should be just a case of plugging it into the internet and, as we Brits say, Bob’s your uncle it should all work as before.
But. In the second scenario take a centre with four devices all happily running in a centralised, local, server. Then fleet reduction dictates one device needs to be sold. At the new location this will require access to a server to run the load which adds to the cost.
We mentioned above that the reliability of the internet is not what it could be everywhere and even running on a local server the risk is that a problem would take down all that centre’s devices simultaneously. Similarly cyber security becomes a risk factor; we know of two operators of traditional devices who have lost time due to ransomware; there are some vicious people in this world who might consider a major airlines training centre with multiple devices a very juicy target.
We can also imagine the case of a TDM going out of business and taking all the simulators it is hosting on its servers offline in one fell swoop. Or maybe even just cutting off access because of a disagreement with a client.
Oh, and with both scenarios there is the small matter of licensing of the load and data licences.
Oh and what about the regulatory implications?
The first thing that came to mind for us was configuration control, take the situation where let's say 50 FSTDs were running the same load. This is then updated by the TDM, are there to be 50 individual acceptances before the new load goes into training? And imagine an operator who informs their authority that they are not sure why the load was updated, the TDM didn’t give us the choice, that's not going to end well.
But addressing the configuration control is achievable we think as long as the challenges are understood and properly addressed. Then it largely comes down to maintaining the QTG, and for that does it really matter where the load is running?
We also noted that at the same conference SIM OPS delivered a presentation (see also our blog “The end of recurrent evaluations”) advocating a move to Performance Based Oversight (PBO)² and cited the situation where an operator has multiple FSTDs on a site all running the same load. Perhaps a virtualised future running either on premises or on the cloud adds to this argument.
Is this a potential area for an Arinc standard?
The thought did briefly occur to us that if a common interface standard could be agreed it would actually be possible to change an FSTD’s load from one manufacturer to another just by pointing it to a different internet address (yes we know it would be more complicated than that in reality). Whilst the idea would be attractive for users we can’t see the TDMs agreeing, we fear this would go the same way as previously proposed common IOS interfaces and IG agnostic visual databases. To mangle the old saying, turkeys tend not to vote for Christmas.
How can SIM OPS help?
If you are operating an old device running on obsolete hardware give us a call, the virtualisation we did was very cost-effective.
References
“New Technology to enhance operator management experience” presented on behalf of CAE Inc by Sebastien Bolduc and Hessam Ghiassi, presented at 2023 FSEMC 23 - 26 October 2023 and published 9th January 2024 by FSEMC.
“Recurrent Evaluations - a Requiem” presented by Mark Dransfield on behalf of SIM OPS at 2023 FSEMC 23 - 26 October 2023 and published 9th January 2024 by FSEMC.
Comments