Recently I joined a panel discussion with the team of Quick Release on the topic of Configuration Management vs Variant Configuration Management. Thanks to Rob Ferrone and Omid Hosseinitabar for inviting me. One question I found very intriguing, which had to do with Over-the-Air updates and how this relates to CM.
Over-the-Air updates are software updates that are sent to the product wirelessly to update the firmware, operating system, or system settings/parameters for instance. This has a lot of advantages because you do not have to take the product to the dealer to get the update or plug it into your PC to run an update, if it is a safety issue that can be fixed through a software update it can be done without having to physically access every single product. For example, Tesla updated the software after reports the Tesla Model 3 had a longer braking distance than a Ford F-150 pickup truck, after an update Tesla was able to reduce it by 19 feet or 5.8 meters. Imagine that, just updating the software improved braking distance on a Model 3 by 19 Feet/5.8 meters. That is quite amazing and worrying at the same time. There have been other reports from Tesla owners that their car does not start after an update and had to get towed and even required hardware replacements to fix them. Other Tesla owners complained that after an update, the torque or acceleration was less than before. The worrying part is that with a software update, Tesla but also other Manufacturers can go very deep into the system and impact key functionality and behavior of the product. In the example of Tesla, it can change the behavior of your braking system or the autonomous driving capabilities.
Several things spring to mind:
- Security is key here.
- Nobody should have access or be able to gain access that is not authorized to the software or systems needed to process the update over the air.
- The product or the user of the product must be able to verify the authenticity of the update.
- Screening and testing of updates are critical as well.
- The product must perform and behave as expected after the update.
- A customer does not want the update to brick their product (unresponsive and not easy to fix).
- It must be nearly impossible to do something wrong regarding the update process.
- And in case something does go wrong, it should be relatively easy to fix.
But this is where CM comes in…First you must know all the configurations of the product in the field. And be able to validate it against the state each product is in, to ensure the update will be successful. In other words, a product can be configured in different ways, it might have replacement parts and might have specific user settings defined that potentially impact the function/behavior of the product and the related update. How do you ensure that for all permutations, the update will run as desired and have the desired result?
This ties back to knowing what you build and sell. Based on your sales configurator, you might end up with thousands, millions, if not billions of possible configurations. But you are likely to only sell a certain subset of all the possible permutations (Check out the interview of Henrik Hulgaard by Jos Voskuil on PLM and Product Configuration Management (CLM) to learn more about this). But still, that might be too many to test. This is where system engineering and impact analysis comes in. Understanding the dependencies between functions, parameters, behavior, and the hardware and software components is key to assess the risks and required testing and simulation to ensure the update will work as desired. This sounds easy, but the more complex a product offering becomes, the more products in the field, the longer these products need to be maintained, the more difficult it becomes.
If you work with over-the-air updates, I’m curious to learn how you ensure that the update will run as desired and have the desired result. Feel free to leave a comment or contact me to share your experience.