Factors affecting the migration of a large embedded system

Abstract

Migrating a small project can be a hard thing to do. Migrating the code at a large company is even more challenging. In this thesis, the focus is on trying to find common elements in how a large automotive company migrates their embedded code.

We interviewed ten people from various teams to find common topics that make it harder or easier to migrate. We also developed an architecture recovery tool called GRASS to look at metrics such as fan-in and fan-out of the source code made of C code. During the latter part of spring, we held a focus group with the people interviewed.

By combining these data, we found that it is harder to migrate code if a team has dependencies on many other teams, or if there are hard dependencies on the supplier’s code. GRASS was able to identify these aspects, but the interviewees thought that GRASS needed improvements in order to be useful to them in the migrating process. Additionally, the hardware aspect of an embedded system can make it harder if the hardware is limited in capacity, or if there are real-time requirements that make latencies in the system unacceptable. Lastly, we found that some teams had small parts that they were able to automate, and these automation scripts might be useful to others.