Along with managing change, there are other development challenges, such as coordinating globally dispersed design teams, integrating across different engineering disciplines, and closing the loop from requirements to validation.
The survey results raise the question of what product development organizations need to do to take on these challenges. Not surprisingly, the answer involves both organizational change and technology. Companies that fared better and avoided some of these challenges had more integrated team structures, as opposed to separate teams for mechanical, electrical, and software engineering, the survey found. In addition, system modeling was a key way to avoid problems, though only 12 percent of respondents said they consistently create system models.
The other linchpin in surmounting the development complexity is technology -- specifically, some sort of structured lifecycle management approach, which is obviously where the PTC connection comes in. PTC and Brown make the case that companies using product data management (PDM), product lifecycle management (PLM), or application lifecycle management (ALM), particularly a platform that is integrated across disciplines, will have more opportunity to avoid the problems that arise from software-driven complexity than companies using point solutions or simple document management tools and email.
The findings are meant to play well with PTC’s product story. The company made a big push last year to embrace embedded software development as part of its PLM platform with its $306 million acquisition of MKS, which markets the Integrity ALM platform. Yet beyond any market positioning value, I think PTC and Tech-Clarity have defined some very real challenges for product development organizations, particularly as products shift from a heavy reliance on traditional electronics and mechanical components to lines of code.
I’d love to hear how the Design News audience is dealing with these challenges and what kind of wrinkles software development is adding to traditional design processes? Discuss in the comments section below.
Beth, nice article, and very timely. The first thing that comes to mind is that many organizations doing embedded design have hardware engineers doing software. The reason for this is that most people think that anyone can write code. I have seen it. And yet, we have, as your story points out, more and more software content in products. I get involved in judging senior projects at some local universities from time to time. These are all in hardware disciplines. In each case, there is a microprocessor invovled. The main reason for this is the complexity of some of the projects. There is simply not enough time to develop a hardware solution, even if they could get it built. On the other hand, the students do not have a good background in software and point out that this was the most difficult part of their project. The schools are attempting to remedy this.
My background is in the spacecraft industry. The projects were large and complex and expensive. We had a strong systems engineering group. We also had functional teams with all the various disciplines. There were several mechanical (mechanisms, stress, thermal, materials, etc.), electrical (power, logic, controls) and software engineering. There were also manufacturing engineering functions and a large engineering support group (read drafting or CAD). A project would draw people from each of the functonal groups. So, by design, we had the multidisciplinary teams. This worked well. We often used system design languages and made the decision of whether to implement in hardware or software well down in the process.
In recent times, I have been more involved in the commercial embedded world (among other things). I notice things coming into vogue such as requirements traceability, higher level languages (C++ for C) and OOP techniques. These things are being supported by the CAD vendors and are being driven, I think, by the involvemen of the software engineers.
I think we will see a real shift in how these projects are done as these techniques are applied more widely.
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 discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.