Four Ways to Detect Undesired Changes During a Tool Version Migration
When developing functions for automotive ECUs, there are many reasons for migrating to newer tool versions. For example, security conscious IT departments might insist users move away from versions that are no longer supported (e.g. Windows 7). Also, tool suppliers are always adding to features to that are more efficient and make the developer's life easier. For example:
New AUTOSAR versions
Improved enumeration handling
The latest or better code optimization algorithms
Also, improvements that impact the everyday life of model-based developers and testers with new features in interactive workflows are a strong factor. For example:
New TargetLink Property Manager
Quick-Insert for library blocks in Simulink, etc.
Wouldn't enhancing the ability to produce the right code or better code motivate you to move to newer versions...? And even more so because motivated individuals produce the best results?
We will explore four different approaches to detect undesired changes introduced by a tool migration, resulting in an optimized workflow that can be fully automated.
Vice President BTC Embedded Systems, Inc.
Pilot Engineer BTC Embedded Systems AG