Have you ever heard of the Voron-Project?
There is a high chance you haven’t! 🙂 However, I am pretty sure you have heard about 3D printing!
If you – like me – ever started 3D printing as a hobby, you wanted to get to know and understand every detail. The first parts I printed were parts for my 3D printer (an Ender 5 Pro), like a modification from a Bowden-Extruder to a direct drive with several addons.
For a good print result, there are many parameters to consider. Just to name a few of them, the filament, the temperature of the nozzle, and the nozzle itself; the type of print bed and temperature, the adhesion of the first layer, the layer thickness; the travel and volumetric speed, which support structures to use, etc.
In addition, the devices are only so cheap, especially the consumer devices, because inexpensive components are used. But it is also part of the hobby to face this challenge and to invest your time in constantly optimizing and calibrating your printer for achieving the best results.
The Voron Project
The Voron project was launched in 2015 when a group of engineers set themselves the goal of developing a no-compromise RepRap (filament) 3D printer. Since then, the project has made steady progress and now offers plans for several high-end models.
The Voron team itself does not produce printers for sale, but only publishes the blueprints and documentation, in order to promote the open-source philosophy and enable broad community support.
To be honest, I’m excited about the idea of building one on my own; I have a lot of respect for these DIY hobbyists. You can also get a very good consumer device for the same money. However, this project is not just about setting up a prefabricated 3D printer and getting started but is on a completely different level: you must build the device from scratch. This includes the housing, the mechanics, electronics, and the complete cabling, along with then having to install and configure the software and calibrate the device. If there is a problem, there is a helpful community, but no support from a vendor. Sounds like a great and fun challenge if you’re doing 3D printing as a hobby.
As much fun as a DIY project like this can be and as much as you can learn about the interplay between mechanics, electronics, and software, I think we can all agree that nobody would ever think of building this device for professional use. What matters for professional use is reliability, a long service life, good support from the manufacturer and as little time as possible for the setup. You need high printing speeds with high print quality in order to be able to operate efficiently on the market.
For professional use, you want to use a professional device and not start tinkering again with every small change.
Industry Standard Tools
But what does this have to do with the development and testing of embedded software? Well, I have already seen self-developed test solutions at various customers. These were developed exactly for the use case that the customer has. It usually started out small, but over time more and more resources were poured into the project. The documentation is often only rudimentary and in people’s heads. If the developer who knows the most about it then leaves the company, you have a problem, and a lot of time has to be invested again until the next person has familiarized themselves with the in-house project.
The tool often has to be updated again because the development environment and APIs change (e.g. new Matlab version, new AUTOSAR version, etc.), or people shy away from any change because it involves a huge amount of work. And unlike a hobby, in a business environment time equals money.
And to complete the analogy, like in commercial 3D printing, professional tools are also used when testing embedded software. In return, you have the resources available, receive support and regular updates, as well as trainings.
One argument that is sometimes put forward is that an industry standard test tool does not offer the testing options that you need for your project. There are certainly cases where this is true, but there is usually a reason why industry standard tools are developed the way they are, and it is a good opportunity to reflect on your own testing process to see if it really needs to look exactly the same as it does today. Years of experience from many projects and many companies flow into these industry standard tools. Not to mention that these tools can be usually customized and extended with project specific plugins.
Over the last 20 years, more and more standards have been developed for embedded software development, such as ASPICE, ISO 26262, AUTOSAR and, last but not least, model-based software development and testing. Other standards such as SOTIF and AUTOSAR Adaptive are currently being established. In addition, automation now plays a very important role in keeping manual effort to a minimum. Taking all this into account is a major challenge for a self-developed in-house solution and it is doubtful whether it would be profitable.
Conclusion
The illustrative example from the 3D printing sector as a metaphor for testing embedded software makes it clear that industry standard software is now established in testing. Nobody questions the fact that you use tools such as Word, Excel, PowerPoint, MATLAB, Simulink, TargetLink or Embedded Coder and do not develop them yourself. So why not the test tool too?
The resources that a company must invest in the development of in-house solutions are considerable in the medium and long term. The maintenance of the tools in particular often takes up more time than expected and slows down important further developments for the actual product that you want to sell. In this respect, the use of industry standard software not only pays off in terms of the effort and costs for a test tool, but the company can also invest the freed-up resources in the development of the embedded software itself.
