How to Share Learnings Across Multiple Products

One of the most exciting new ways to create value using artificial intelligence is the concept of reusing data gathered from an old product to improve a new product. The concept sounds simple, but it is not exactly easy to implement for complex systems. You will never be able to predict the performance of a rocket based on the performance of your bicycle. However, the flight data collected from A320s are definitely useful for the engineers who had to develop the A321. The most recent engineering projects are usually the starting point for a new project in engineering anyway. So don't think of AI for product data as a miracle tool that will have all the answers. Think of it as a more elegant way to learn from your existing products to accelerate the time-to-market for your new product than leafing through lengthy reports. Here are a few things that we have learnt at Monolith about the science of applying AI to transfer learning from product to product that might help you get started.

1. Think "next"

When setting up your first product to product ML (Machine Learning) model, think about the next design iterations and how they will change your product compared to your current design. To help, you can also look back and see how your current design is different from historic ones.

Here are some best practices to make sure that the inputs and outputs for your current design are relevant for future designs. This could be applied to anything, but let’s take the example of the wing of an aircraft.

Try to think about:

  • What will vary in the new design? For instance, for an aircraft, the size or the shape of the wing will vary. There might be additional or different features on the wing, like the number of ailerons, flaps or slats, the presence of a winglet to decrease the drag. For a car, that might be the type of material used for the bumper, the presence of a spoiler at the rear of the car.

  • What will remain the same in any new design? For instance, you might know that your aircraft will always have two wings, that they will contain two fuel tanks, or that your car will always have four wheels.

  • What unit to use? Should you use an absolute unit (e.g. meters, tons, …) or something relative to the plane (e.g. percentage of the wing span, ratio, …).

The same considerations are important for the data you want to use as outputs for your ML model. What results are you interested in, and in which format should you store them so that they can be reused the ML model on new designs?

It is hard to think about “How can I keep track of how to differentiate the next design from the current one?”, but it is very rewarding! It’s a difficult task because it requires forethought about how the next products will be different. Sometimes, it is impossible to know what will be changed in future designs, especially for components that differ greatly from one generation to the next. But it is always possible to think about what can be changed in the current design.

Try to avoid labels classifiers and prefer continuous numerical value.

Some information might be currently stored in a format that only makes sense for the current aircraft. Some locations or other inputs can be coded in a way that restrict your ability to extend learning to new designs. These categorical variables almost always hide other more useful numerical values. If you can translate the labels into numerical values which describe how your design is different from others, the differences are expressed in a clearer way. Moreover, if you come up with a new design that requires a class that your model has never seen before, your model will not be able to make predictions.

For instance, instead of storing the location of the airplane engine on a wing as LOC_ENG = ABC.123.D (a made-up category), it is better to store the distance between the wing-root and the engine as an explicit distance such as d=9.50m. That way, a model will be able tolearn much more information about the connection between distance and performance, and it will also be able to predict outcomes for new unseen engine-location categories.

Here is another example for material properties. Instead of defining the material of a car component as AA6061 (standing for Aluminium Alloy 6061), you would learn more from material properties such as the stiffness E=69 GPa and the strength S=200 MPa of that aluminium.

Standardisation and parametrisation of your designs (and their corresponding results) will also require some efforts and thinking, but they will be hugely valuable in the longer term. It will make your data much easier to exploit, not only for ML purposes but for any other data processing you might want to do! Regarding 3D data, it might be much harder (or even impossible) to manually parametrise your historical designs. That is where tools like auto-encoders can help you create structure in your 3D data (to know more on this, check out this article from the same series).

2. Example of an aircraft wing

Imagine we have designed an aircraft wing in the past. We have run many expensive simulations and experiments to know how the stress along the wing structure behaves. The data collected are the stress at different sensor station locations along the wing. We know we want to train a model that can make new predictions for the same aircraft, but we also want to re-use this trained model for a new aircraft in the future. Let’s have a look at two different ways to prepare your data, and how they affect the possibility of transfer learning.

a. Without any data preparation

In this first case, the data collected after designing the first aircraft (in blue) are not transformed in any way. There might be some “shared parameters” that will also apply to a new aircraft design (such as speed, altitude, and weight), but at least two issues might arise:

  • There could be “unshared parameters” that are too specific to a given design and cannot generalise well to a new design (such as the station numbers, or the station number closest to the engine).

  • There could be missing “differentiation parameters” that can quantify the difference between your designs, such as the full dimensions and shape of the wing.

As a result, it is unlikely that a model developed for the first aircraft (in blue) will be of any use to predict the results of the second aircraft (in red). First, your trained model simply has a different number of inputs and outputs. What input values do you use for the missing or additional parameters? And what values do you predict for the new outputs? Secondly, the model might make predictions that would only make sense for the first aircraft. For example, as the load at the wing tip is always close to zero, the model will learn to predict a load of nearly zero at station 30 for the first aircraft, while for the second aircraft, the load at station 30 will be far from zero!

The absence of data pre-processing means that the model trained for the first design cannot be re-used on the second design.

b. With data preparation for ML

In the ideal case, all parameters are shared between the two designs. This requires the data to be processed:

  • Stations numbers and positions are converted in lengths and ratios instead of being a “hard-coded” value

  • The “differentiation parameters” are added to make sure that the difference between different designs can be captured.

The outputs are also transformed to be useful. Instead of predicting the stress at station number, the relative location along the wing can be used. Another solution would be to separate predictions between the stress between the fuselage and the engine, and between the engine and the wing tip.

Data pre-processing allows the same model to be used on different products.

Training on a single design will very rarely provide a good enough model to predict the results for a second design. The effect of the wing length cannot be learnt if the model has only seen data for a single value of the length. But now, the model will be able to learn the effect of this parameter as data from more designs are gathered.

3. Conclusion: Future-proof your models

Setting up an AI solution for your current problem will help you understand it better. But if you think about how it can capture the evolution of the product over many iterations from the beginning, your model will be far more valuable. This exercise requires time and effort to think properly, but that will be greatly rewarding in the end.

Share this post

Apply to Monolith

Ready to get started?

BAE Systems
Mercedes Benz