RD3: eLearning Made to Order
If you were to compare our eLearning portfolio with that of our competitors, you’ll notice that we propose aircraft model-specific courses as opposed to the generic “one size fits all” solution used by most other online aviation course providers. For example, we offer an A330-200 course as opposed to a plain A330 course that covers all of the different variants.
There are several reasons for using this model-specific approach. Most importantly, we want to make sure your courses address the specific aircrafts you use without providing extraneous information that isn’t valuable to your pilots. If your fleet consists of A330-200s aircraft, why would you want to train using materials that cover both the -200 and -300?
Another reason we prefer this solution is that it more effectively addresses items such as the imperial versus metric problem. One approach is to cover both systems concurrently, but this makes it more confusing for the end user. The better solution is to create an imperial version, and then a metric, and then let the user decide which one they want to use.
Customizing Course Content with a File-Based Approach Creates Challenges and Inefficiencies with the Process
How can this problem be managed? One way is to come up with a very specific course – for example, an A330-200 course using the metric system, and covering the PW engines. Then copy the file, rename it something different, and turn it into an A330-200 course using the imperial system, and covering the RR engines.
The A330 can be powered by three different types of powerplants, so in order to offer a model-specific course, you’ll need six versions of the A330-200 course: one for each engine type, and measurement standard.
Keeping in mind that there’s probably 90% commonality between these 6 versions, you’ll quickly realize that there’s a problem with the file-based approach: if you make a change to one course, and this change happens to affect the others as well, you’ll have to make changes in all affected copies. If the change affects all copies equally, then there’s no problem. However, the process becomes complex if the change only affects certain copies.
RD3’s Cloning Feature Simplifies the Course Customization Process
Fortunately, RD3 makes it very easy to manage this particular type of problem. It incorporates a feature called “cloning.”
Cloning typically involves making an exact copy of something. However, RD3 cloning is slightly different: we make an exact copy of the important information such as the file paths and datasets. But we do modify the record management part.
Let’s look at an example to illustrate how this process works.
We just completed the New Engine Option course for the Airbus A321. However, we know that there’s a need for an A320NEO version, so we’ll use RD3 to clone the A321NEO and then turn it into an A320NEO.
The first step in the cloning process is the definition of a project ID. This is a unique identifier that is used for the collation of data.
From the screen shot above, you can see that we’re cloning the A321NEO-C16 project. This clone needs to have its own unique identifier, and since we’re making an A320, we’ll use the A320NEO identifier. Also note the Company ID. This is a code we assign to our customers, so adding the Company identifier to a project ID enables us to create a company-specific version. In this case, we’re using C16 since this is a spec project for us.
We also specify the name of the company. It’s used because humans understand A320NEO Avsoft International better than they understand A320NEO-C16 (C16 is our company code).
Then you get to add a description.
Finally, you select what you wish to clone.
Since we’re coming up with a variant, we need to clone the ATA table – the database table that stores the name of the module and the ATA code. The reason we clone this is because we also store a reference to the development forum in this table. If we just piggy backed off the A321, we would be using that project’s forum.
We check CBT because we want to make modifications to the narration of the A321NEO course. Since we don’t expect a large number of changes, we want to avoid having to re-record all the audio, so we copy all the existing audio clips, and then we only re-record the necessary sections.
Detailed Record Identifiers Make it Easy to Determine the Specific Variants to Change
So far, the RD3 process has been very similar to what would be done using the copy/paste file-based approach. But when it’s time to make changes post deployment, it becomes much easier to figure which variants need to be changed. The reason is that when we clone the data set for the CBT itself (called the narration dataset), we keep track of the original record reference.
Every record in the database has a unique identifier. It’s usually an integer, and it increases by increments of one for every record that is added. A record number is never reused, even if that record is deleted.
The screen shot below shows part of the dataset for the A321NEO course, and the unique identifier is in the first column.
When we cloned the A321NEO into the A320, we copied the records and re-injected them into the data table. In the process, new record identifiers were created as indicated by the left-hand column.
But take a look at the right-hand column. We noted the identifier of the original record. For example, the 6th record of the A320NEO project has a record identifier of 395760 (left hand column), and this record was copied from record 385116 (right hand column).
If you look up record 385116 (first table above), you’ll see that it’s the 6th record of the aircraft general module of the A321NEO course.
If a change needs to be made to the graphic for the 6th screen of the A321NEO Aircraft General Module, our eLearning development team will make the change, but then search the data set for any references to the 6th scene. Any records that match will be examined to determine if the change applies there too.
If you work with complete files that are duplicated and modified, you’ll have to open each file in turn and examine the file to see if a change is warranted, making that approach time consuming and error prone. The use of specific record identifiers streamlines this aspect of the process, allowing our development team to make all necessary adjustments quickly and accurately.