“The magic power of the software parameter” an article by Dr Henrik Fagrell
The last newsletter on part numbers triggered some questions about another object of versioning and configuration, the parameters. But let’s first do some time travel…
About 25 years ago, as a PhD student in my twenties, I met Gideon Kunda at a seminar talking about his recent book and research. Even though I had limited personal experience from the inside of ‘Tech’ organizations I was struck by Kunda’s catchy points. One thing he said that been with me ever since was something like “Hardware engineers and Software engineers look the same for an outsider, but they have a totally different at a closer look, republican vs democrat, navy haircut vs no haircut, beer vs marijuana, etc.”
True then, and today is that engineers do group into sub-tribes. However, I might add that corporate culture is often more dominating than craftsmanship or even national characteristics. Software engineers at Volvo Group IT Poland and Bombardier Poland are colored by their corporate culture, and you cannot tell it’s only Polish.
Okay, back on track, in the automotive sector I have observed a mysterious product configuration matter that today remain debated between hardware and software people, the software parameter. To limit the number of maintenance objects a software is usually designed to have parameters to handle product variation. For example, the same software can be configured to activate or de-activate advanced features. This could radically change the product behavior. In the hardware world this would require magic…
This magic leap is an everyday practice in the software world but playing with such powers requires responsibility. The complexity will blow up in your face. For example, a trivial product consisting of say five software parts, each with 10 Boolean parameters would give over a quadrillion of variants in theory (1 125 899 906 842 620!). The general idea that some combination of variants that have not be verified are running in a passenger car driven at 130 km/h on the freeway with a family with children, scars the living daylight of hardware engineers.
The responsible side of the hardware persona should be used to address the problem. So, it is important that the is software designed so that each parameter introduced
- follow the form, fit and function rules
- is tracked throughout its life cycle (introduction, deletion, instanced available on products in the field)
- have a safe upgrade path from previous versions to the lasted in use
Also, complexity should be reduced by grouping parameter sets with version control on a higher level (e.g., via checksums or old-school part numbers).
Hats off to the hardware engineers who shaped my thinking in this matter, and a long lost thanks to Professor Kunda that once configured some parameters in my young stubborn head into this path…
Are you facing similar challenges? Please do not hesitate to contact us at sales@diadrom.se
Kind Regards
Henrik Fagrell, PhD, +46733 31 11 10, henrik.fagrell@diadrom.se
Viktor Eliasson, VP Sales, +46733 31 11 15, viktor.eliasson@diadrom.se
