A vast amount of the innovation in today’s automotive industry is driven by software. While it is obvious that the complexity and size of software in a vehicle is growing, the actual growth rate is really astonishing. According to a study by Accenture, we saw a growth from 50.000 lines of code in the 1980s to up to 10 million lines in 2008 to up to 100 million lines today. At the same time, the software share of the total value of a vehicle grew from 8% to 40% and will reach over 80% in the future.
This dramatic shift in value creation from hardware to software is in particular a challenge for companies with a strong history in hardware development and production, which now need to start developing software. Due to the somehow “virtual” nature of being just bits & bytes on a hard drive, the impact of software complexity on the development and test process is often not that obvious.
So, let’s try to compare it to an example from a different domain: Building a house.
Small Project
Let’s imagine we want to build a little doghouse to put in the yard. We would probably decide, that we can mostly do it by ourselves. We wouldn’t need too much planning, as the impact of making a mistake in the process would be small. We would go directly to a hardware store to buy the material and some small tools like a hammer. And we might do the “testing” just at the end of the project: As the whole thing is not that much effort, we can easily go back to the beginning if we did something wrong.
To translate this type of project to the world of embedded software, let’s assume we only need a couple of 100 lines of code (not sure if those types of projects exist today). We wouldn’t hire a large team of different people with different roles, we would maybe just open a text editor and start typing, as we can easily keep the small set of requirements in our head. For testing, we might just flash the code to the target processor and do a system test.
Medium Size Project
Now let’s look at something slightly bigger: If we want to build a house to live in, we would obviously first decide that there should be some more people with different roles involved. We’d have an architect, a structural engineer and different people to work on dedicated tasks on the outside and the inside of the house. Instead of immediately starting the construction, we would first make sure to have a detailed plan for the design, the project timeline and the cost. The project will also require some bigger tools (e.g. a power shovel), as not everything can be done by hand. The “testing” would not just happen when everything is ready, we’d rather check the work product of each construction step before going on the next one. When we already have the roof finished, we might not be able to go back and change the whole basement.
Translated into software, we will first start with identifying different roles like requirement engineer, function developer or test engineer. We will also have some process planning and some requirements documents, so that everybody has the same understanding of what should be done. Regarding tools, we might use a model-based development approach with Matlab/Simulink, a code generator like dSPACE TargetLink and a test management tool like BTC EmbeddedTester. While some professional tools will clearly be needed, we might still use a basic SVN for file and version management and maybe also use Excel for some tasks. When it comes to testing, we will test each software unit independently with sufficient code coverage before doing any kind of integration. While a nice thing about software is the possibility to still do bugfixes in a late stage of a project, it is not very efficient as the cost for finding and fixing software problems dramatically increases the closer we get to the final product.
Large Project
A large project like a skyscraper is in general not that different from the previous example, except that everything is again one order of magnitude larger. We’ll see more people, more powerful tools and even more planning and preparation to avoid surprises towards the end of the project.
For a software project, it would mean that in addition to what we had before, we’ll need some professional tool support for things like data management, variant management, issue tracking, system architecture and software architecture. This could involve toipcs and tools like SysML/UML/Autosar tools, PTC Integrity, dSPACE SYNECT or JIRA. We’ll also need to make sure that the work products created by different developers are consistent and compliant with project or company guidelines. This would in particular require tools that look at modeling guidelines (like MAAB) and coding guidelines (like MISRA).
Conclusion
While the impact of project size and complexity is usually obvious for hardware related projects, it is a bit more difficult to see for software projects, as the difference in the final product is “only” the size of some files on the hard drive. But the challenges in both types of projects are actually not that different. For embedded software, standards like ISO 26262 give guidelines that help to pick the right combination of development and test methodologies. For any kind of project, be it building a house or developing embedded software, there is no one-size-fits-all solution regarding tools and processes.
