A factor that can be a huge asset in meeting requirements and tackling challenges is a software-driven development approach. This is true even in physical product engineering.
Turning an idea into a viable product can be challenging. Tight delivery schedules have to be met, trade-offs understood and managed, and the competition is also never far off with similar product ideas and designs.
A factor that can be a huge asset in meeting requirements and tackling challenges is a software-driven development approach. This is true even in physical product engineering.
It’s been ten years since Marc Andreessen published his essay in The Wall Street Journal stating that ‘Software eats everything’. This has already come true in some fields with the continued rise of mobile and cloud computing. Especially in physical product development there has been a big shift towards software-driven methodologies.
In this article, we discuss a recent example from our project activities.
The answer to this question is no. A client, active in technical products, approached us with a request to build a lab sample embodying his latest product idea as the starting point in a product development project. We reviewed the requirements and found some that were challenging with regard to the technology, others with regard to the timeline.
Initially, all of our thinking revolved primarily around the question of how to build that physical lab sample.
By physical I mean all sorts of tangible parts, such as the controller board, the display, some keys, actors, sensors, frame, housing, and so on. The prototype would, of course, need some minimal software, but the emphasis was on ‘minimal’, as in just to control the inner processes and to provide a basic interface.
In addition, the lab sample was to be made of carefully selected hardware components that were believed to be essential for fulfilling the requirements. And building something physical such as a lab sample is what one would typically do in the early stages of product development, so why question it?
The turning point came when our client informed us they had discovered that the Unique Selling Point would be defined by something other than just those special hardware components. Aha!
Instead, key features were the way the user was to be guided through the workflows, and the general flexibility and controllability of the device. That immediately made us switch our thinking from lab sample to software-driven innovation. We suggested putting the lab sample aside for later and starting with software instead. The software would be connected to a remix of existing products, so all that needed to be done was to connect those products to the software and to provide access in the program to the actors and sensors. Add an automation layer using scripting, status monitoring, domain-specific logging and a control layer, and the customer would be ready to use the setup to experiment with a product that did not (yet) physically exist!
By automating everything with full access to the hardware, enriched by the full flexibility of a scripting environment, the ‘lab software product’ can be used to determine the relative importance of features, and further, what is and what is not important in the realisation of these features.
For example, it was assumed that incorporating accessories would be complex. When looking at this from an information point of view, however, one of the planned accessories – an additional temperature sensor – would become just another data source for the main actor’s control loop. Moreover, the extra data source could now be used, or ignored, depending on the state of the process to be executed. To establish when to use and when to ignore, one can script as many flows as required, analyse the log outputs plus the physical results and adapt parameters accordingly. If that does not do the trick, the log data can be adjusted in accuracy and tagged with timestamps or other meta-information. Load the log data for further data analytics, and you now have the possibility of finding correlations which had not been detected before.
So far, we have talked a lot about software, but how do we proceed from there?
Once the flows and use cases are running on the mimicked hardware, you will be able to recognise and understand the hardware requirements. Effectively, you will have the means to save hardware costs and avoid expensive and time-consuming hardware iterations during the product development cycle thanks to those insights.
You can then start to develop the hardware and port the software incrementally to the ‘real’ hardware. To test for success, you have already built a reference system, with which results can be compared. Consequently, all that remains is to continue with agile product development as usual. Here is the name of the new game: ‘Hardware follows software’.
Gernot Trautmann is a Business Solution Manager. He is part of the Solution Center ICP (ZDE) and is also member of the Market Team Consumer Goods.
