Engineering Design Teams in the Age of IoT

Design teams often have members whose engineering disciplines are mechanical or electrical. Occasional and intermittent different disciplines are added to the design team, depending on the given product and its application.

The SOLIDWORKS ECAD/MCAD collaboration server facilitates linking mechanical models to electrical data in a single managed project. Image courtesy of SOLIDWORKS.

However, the IoT calls out the need for a solid interface among mechanical, electrical and now software developers. This could bring a different tint to the design team of yesterday, while presenting new challenges such as integrating suitable software tools and melding different technical cultures.

“As more products are becoming IoT connected, more companies are becoming electronically-focused versus mechanically-focused,” says Steve Chalgren, executive vice president, Product Management and chief strategy officer of Arena Solutions. Arena offers PLM (product lifecycle management) and BOM (bill of material) software that is focused on the integration of multi-discipline design teams.

This newfound focus will require more emphasis on software architectures and designs to accommodate IoT applications.

“IoT will definitely challenge traditional software packages. IoT devices require additional considerations––for example, wireless communication protocols, that traditional devices do not necessarily consider,” says Ervin Sejdic, Ph.D., assistant professor at the Department of Electrical and Computer Engineering at the University of Pittsburgh’s Swanson School of Engineering.

Engineering design software providers must ensure that their products allow effective collaboration and integration.

“What if you [were] to design a car seat that will alert drivers if kids are not properly fastened during driving?” asks Sejdic. “Traditional design software tools, such as CAD systems, typically offer capabilities for mechanical design, but to design wireless protocols, you would need to use different software packages. Hence, a new comprehensive software package is needed. However, the question is who will offer such a package, especially as these software tools are designed by specific companies with a narrow expertise.”

Many Tools, One Effort

Different engineering disciplines have become comfortable using the tools that they are accustomed to. They don’t want to forgo this familiarity; they hope to retain it. But is the digital design community ready to accommodate many tools for one effort?

“With traditional discipline-specific design tools, there are definite challenges with developing in a multi-discipline environment desirable for the creation of connected products,” says Louis Feinstein, senior manager, Portfolio Management for Dassault Systèmes SOLIDWORKS’ ECAD products.

Feinstein says that SOLIDWORKS is continuously developing applications by being mindful of the integration of electrical, electronic and mechanical design integration, without data translation between the disciplines. He adds that existing design communities have always posed cultural barriers, and that the challenge moving forward, particularly in the age of IoT, is to make interaction among such communities seamless.

According to Chalgren, companies who may have focused on mechanical disciplines are adding electrical and software engineers to their staff—which means they are looking for PLM features, and he says his firm has already anticipated this emergence. “We are quite happy with the growth of IoT and see a significant opportunity to provide capabilities to companies that are adding electrical and software to their mechanical offerings,” he says.

Chalgren adds that different disciplines working to the same end is nothing new for design teams of all sorts. Different teams of different disciplines are accustomed to collaborating and integrating with other disciplines. The challenge is when others use different tools—and may just have a different culture within their specific design community.

“Electrical and software engineers have been working together on high tech, consumer, data center and medical products for years,” says Chalgren. “The integration points of each of their design tools have been pretty much worked out. Further, the mechanical teams that work in high tech have largely worked out their integration points too.”

In today’s design environment, collaboration is more important than ever and it is important for all disciplines in the collaboration team to realize that their design tool is not the center of the multi-disciplinary engineering universe.

As Chalgren advises: Retain design tools the team is familiar with. Ensure all team members are comfortable with the software tools that they have used and that others use. If it’s working for one discipline, try to integrate it as best you can with other design tools and applications.

Better Visibility into an IoT Design Ecosystem

With a broader team of disciplines and the use of products now networked via IoT, there are some definite benefits. With the IoT as part of the design paradigm, there is heightened visibility into product development and the product’s use as customers adopt it.

“IoT represents a lot of cool new things to a lot of people,” says Chalgren. “However, when it comes to IoT, the big opportunity is the data stream of telemetric information from all these devices back to the development team so they can finally see what is really happening to their population of installed products. Now, the creators of the product can see the behavior of it, singularly or in aggregate, as they are being used by their customers.”

Not so long ago, customer visits were required to see products in use by end users. Now, with the internet and specific digital intelligence as part of their design, they can often monitor product behavior in real time, and at any time, wherever they’re located.

“IoT now enables the engineer to see 24/7 behavior of all their devices,” says Chalgren. “They can track their environment, feature usage, failures and even remotely update the firmware and software proactively, preventing issues from becoming customer complaints.”

Melding Design Cultures

For a team interdependent on the product design skills of mechanical, electrical and software professionals, perhaps one of the most dominant challenges is the cultural barrier among the players. Each has its own unique culture, but successfully melding these cultures together is a key ingredient to a successful design team.

“The barriers aren’t just software vs. mechanical and electrical,” adds Chalgren. “All three of these disciplines are somewhat different. For instance, mechanical-focused PLM is quite different than electrical-focused PLM. The reason is that the way these teams work and design is different: Different paradigms, different general personalities, different skills and different types of documentation.”

“At the core,” he says, “electrical engineers communicate how to build their product by carefully documenting their design in a BOM. The BOM is core for electrical engineers.”

Mechanical engineers are not usually very BOM focused. They communicate how to build their product by using the MCAD model, or more often, a stack of part and assembly drawings. A BOM can be used by the mechanical engineer, but it is usually relegated to a reference document with the rule that the drawings and the parts listed on the drawings trump the BOM.

“That is a big difference, and it shows in their choices for PLM,” Chalgren adds. “Software engineering is also quite different as they aren’t making a physical product at all. The code is built against requirements. The process is much more fluid—more like writing a novel with tons of iterations, quick releases and quick adjustments. So all of these disciplines are different, with different personality traits, different tools and different deliverables—where do they intersect and how should that work?”

One Common IoT Vision

When creating a multi-disciplinary product, it is key to make sure all teams have a clear understanding of the objective and have a transparent and easy way for everyone to see what is going on—good and bad—in their combined development effort.

A product created by a multi-disciplinary product team always demands clear communication by all stakeholders. The need for transparency is great from discipline to discipline and from team member to team member. Communication has and always will be paramount whether it is within the collaboration tools and software or within the interpersonal communications of members.

“The key need,” concludes Chalgren, “is an agnostic development platform where each design discipline can publish their part of the design; starting at proof-of-concept and prototypes, all the way through to full production.”

More Info

• Arena Solutions
• Dassault Systèmes SOLIDWORKS
• University of Pittsburgh