A new survey conducted by Tech-Clarity for PTC shines a spotlight on what the players are calling the innovation complexity conundrum surrounding software-intensive products as more offerings industry-wide are putting more emphasis on software as a key differentiator.
Of the more than 100 companies interviewed for the survey, 53 percent said they were increasing significantly the software makeup of their products, and 57 percent said software was becoming a more integral element of their product design. Fifty-five percent said product differentiation was driven by software, and very few of the companies (2 percent) saw software lessening in importance over the next five years.
PTC and Tech-Clarity highlighted some key examples to illustrate this trend: Some car models are approaching 100,000 lines of code, and in the A&D sector, groups like NASA are seeing increases of up to 500 percent in software as a percentage of their programs. “Of the five industries we deal with most -- automotive, industrial equipment, A&D, medical devices, electronics and high tech -- software is what’s bringing about new capabilities,” said Matt Klassen, PTC’s director of solutions marketing for the Integrity business line.
There are compelling reasons to support this push toward software. Software-intensive products have proven more innovative and can be designed faster and at a lower cost. The survey results support this conventional wisdom. About three-quarters of respondents indicated they use software to improve product capabilities, specifically to make smarter, more innovative products. And 49 percent use software to tailor products to consumers or key markets.
Despite the clear benefits of software-intensive products, there is a price to pay on the development end, according to Jim Brown, president of Tech-Clarity. Increased use of software dramatically boosts product capabilities and can reduce costs, he said, but the complexity that goes along with managing more code can rear its ugly head and lead to poor quality, longer product development cycles, and inefficiencies. In fact, 56 percent of the survey respondents cited challenges around managing change as the biggest impediment to software-intensive product design.
“While there is a tremendous amount of benefit in developing products that take a lot of capabilities from the integration of software as opposed to mechanical parts or electronics, it also adds a tremendous amount of complexity,” Brown said in a Webinar in which he and PTC officials presented the survey results. “Software-driven change has relentless velocity and volume -- the sheer quantity is staggering. Nearly 90 out of every 100 changes come from software.”
ChasChas - A lot of those old products you mentioned can still be restored into usable condition - at least by some extremely talented individuals. (Ever see American Restoration on History Channel?). Unfortnately, a lot of the software based stuff will soon become boat anchors.
In the big scheme of things, the whole field of software is relatively new, and it still suffers a lot from growing pains. There is still way too much bad software out there.
Part of the problem with programming in general is the perception that anybody can do it - because almost anybody can. But there is a huge (and sometimes unrecognized) cavern between "programming", and writing solid, production-ready software.
In my opinion, writing code that is functional, maintainable, and solid, takes a level of expertise that is seldom achieved, even by fairly experienced programmers. However, I think it is true of most fields that the really good work is done by a very small percentage of the people who are truly passionate about what they are doing.
Hopefully as the field of software matures and develops, the quality level will go up, and the development cycles will go down.
Processing power -- CPU cycles are now essentially free, or at least incremental cycles are -- has finally reached the point where graphical programming tools are supportable. They're being used in the real world -- witness the success of LabView -- and they're a big help to mechanical engineers and other non-programmers who need to create software. At the same time, we haven't yet seen the limitations of these tools surface because we're still at relatively early stages and at the same time the tools are still not really applicable for real-time apps and those where user safety is an issue. My point is that we're going to see continued development of drag-and-drop as MEs and hardware-only folks have needs for more capabilities. Then we'll see how far these tools can go.
Once after being subjected to a marketeer's breathless pitch on a worldbeater of a new product, I buttonholed the product's programmer -- what was along for the ride. When I admitted to being puzzled about the utility of some of the "features" of the product, the programmer cheerfully admitted that that Marketing Department had tossed them into the product-definition specification to "uniqify" the product! I mean, how many friends and acquaintenances do you have who have purchased expensive "smart" cellular phones, that have upwards of thirteen or more functions *except the most vital one for a portable product; A Porta Potty), and use them only to make phone calls, text, and play pinball?
I am a mechanical engineer. Look at the old, say, adding machines, cash registers printers, etc. There are a lot of old machines that for the life of me, I cannot figure out what they were used for. At that point, I am sure the mechanical engineers' brain was slowly turning into potato salad.
Then came software, hydraulics, etc. - and the mechanical engineers' sanity was spared.
Now it looks like the software people are going to need to be rescued.
It is time for self-learning and self-programming products.
I don't know what it will be, but it won't be software - it is reaching it's limit.
Model-based design and the ability to use software simulations is something that is beginning to gain traction in automation and control as well. Machine builders and designers will be to reduce development time and costs as these tools become more mainstream. Automation equipment definitely fits into the category of software-intensive product designs; often the basics of the machine's hardware has been developed over decades. But there is a definite need for tools which connect and unify thinking through the design process and the actual code to run the machine. Should be an interesting area for growth in automation.
Agree completly Alexander. I have worked on many embedded projects. Some where a software engineer writes the code for the hardware from a spec, some where the hardware guy does everything himself (out of necessity as you pointed out). The later projects always outperform the former in terms of time to complete and overall cost as well as after/design problems. That is not to say that it should be done that way in every case. Rather, projects should be evaluated from the start as to which method is a best fit. Something that is almost never done.
I think PTC making what is a pretty sizeable investment (a $300 million acquisition) in the software development space shows just how significant this trend is and how important is it that the mechanical, electrical, and software development tools serve some sort of integrated platform as opposed to how they traditionally reside today, which is primarily silos.
Also, Naperlou's description of the multidisciplinary teams at work in the spacecraft industry could and probably should serve as a model for design teams across myriad industries going forward.
Beth, thanks for a great article. I've been hearing about this trend for several years in system design, most recently in embedded systems and then in machine vision systems and networks. It's interesting to see the growth in the importance of software to product differentiation finally reach a > 50% threshold: over 50% of companies interviewed in the survey saying, in more than one way, how important it's become. And the trend has certainly become visible more recently in end-products like cars, industrial products, and medical devices, while it's been continuing to be true in electronics for a long time. Managing the resulting complexity, in several dimensions, is going to be quite a challenge. The first thing that occurs to me is how this may force even more integration of software, and modularization of code, to make things easier and faster.
That's a great point, Naperlou, regarding hardware engineers writing code for their embedded designs, instead of software engineers. I never saw the potential flaw in this, because indeed we've been encouraging engineers who don't have software smarts to learn how to write programs for their designs. So you make a great point. However, I don't think the problem is that anyone thinks they can write code. Hardware engineers are being encouraged to write code out of necessity -- mainly head count shortages. It also short-circuits the necessity for writing out detailed specs/requirements that can be thrown over the wall to software. I.e., the hardware designer has it all in his/her head, and can just happily begin coding. So that enables the company to meet its time-to-market deadlines, with the results that your message predictably implies.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
16 
