In fact this article triggered me to finally join this forum... The topic of integrating the e- and m-silo (but also s-oftware and o-ptics) has been part of my life for a long time. Talking about carradio-sets with built in cassette-recorders and limited space it was quite natural that placement of e-components would be synced with the drive-belt of the recorder competing for the same space. At the time (70's) the Computervision CAD system was our system of choice because it featured one integrated data-base for electrical and mechanical data. Conceived by genius and ruined by later managerial decisions to grow through aquisition with incompatible cie's, as a consequence of which the grand idea died and CV as well... pity and shame! So hooray for SolidWorks to revive this ideal and make true collaboration and concurrent engineering possible accross classical silo-boundaries!
When you talk about syncing electrical and mechanical design it makes me think about cars, and their wiring harnesses. Of course, I don't do too much on my current cars. They are too complex and I don't have all the diagnostic tools. In the past, though, I had cars I could work on (actually take apart with basic tools) and I did. What I noted was that the wiring was always problematic. It was like an add-on, although it was essential. If only they had these tools back then... (and then was a long time ago).
Given the fact that electrical and mechanical systems have been running together in products for decades, I'm suprised the design wall between electrical and mechanical still exists at all. Are there other products that also break down this wall?
@Rob: You raise a good point. The wall is still there, but many of the CAD tools (not just SolidWorks) have been making good strides to break down the walls. Problem has been that the even though the two worlds have existed forever and siloed tools been used forever, as products become more complex, it becomes harder and harder to do the design work in mechanical and electrical independently and avoid running into big, costly problems. Also, PLM platforms have capabilities for managing both kinds of data which is helping blend the silos.
I would imagine the tools themselves don't necessarily change the long-held behaviors. In the automation and control world, some of the vendors also provide change-mangement plans when the new technology requires behaviorial change.
Absolutely correct, Rob. As with any of these design tools that promote multi-disciplinary collaboration, the tool is just the tool. It's the cultural and change management issues that are really the bigger hurdle.
Yes, collaboration usually has to become company policy in order to make sure it occurs. People otherwise would continue to stay with their old habits. I worked for a company that required collaboration on research documents. Each person involved had to offer comments and sign off on each draft, which forced collaboration.
The real issue today is that engineering organizations really can't afford to stay stuck in the same types of over-the-wall collaboration processes and siloed tools. There are too many interdependencies in designs and so much integration required that trying to put systems together at the end of the development cycle is far too risky in terms of meeting rigorous time-to-market schedules, not to mention, incurring the cost of expensive tooling or late-stage design changes.
Beth, that makes perfect sense. Do you have any idea how this is going from a change management point of view? I would guess that the senior engineers are not as bullish on the collaboration tools as the younger engineers who probably worked with collaboration tools during their college years.
Still the problem is getting the engineers to the prototype and prodution floor. They need to envision and comfirm how the techs assemble the product. I think new engineers should perhaps spend time assembling the product. Another venue is problem reporting. And perhaps the experence engineers should revist. I just had a bit of an education on how the techs decided to wye out a cable. Not how I would have done it. But is was faster and easier work. So now I design with additional flexibility as to how a cable is assemblied.
Our electrical and mechanical designs have worked togather for years. Those organizations that choose to allow empire building and isolation are suffering from a deffective culture. OF course, ours were always smaller organizations where the electrical and mechanical people were fairly close to each other, and casual discussions could be started at almost any time. In addition, we had similar goals, and the project leader would always start out a project with a meeting giving all of us a direction to start in. Also, we all had an input as to what the sales man would sell. So we had a headstart on what we would be doing.
From what I hear from engineers and the vendors like SolidWorks, the two domains don't work completely in isolation (that would be impossible in today's day and age of highly complex products), but the tools are not anywhere close to integrated thus requiring a lot of manual passing back and forth of data and no where near in real time. Those traditional workflows with non-integrated tools open the door for a lot of mistakes and omissions--all of which lead to potential design problems. The idea between these integrated tool sets is to minimize those inconsistencies and get everyone on the same page.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
Using Siemens NX software, a team of engineering students from the University of Michigan built an electric vehicle and raced in the 2013 Bridgestone World Solar Challenge. One of those students blogged for Design News throughout the race.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
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.