IoT Product Design Calls for Embedded System Savvy

With National Instruments’ LabVIEW and PXI PC-based platform, engineers can build and test software and hardware designs with a single platform. Image courtesy of National Instruments.

As a design engineer, you know how to push CAD to its limits to translate a semi-formed concept into a refined design. Perhaps you’re even the resident authority on thermal dynamics and the resource everyone taps to help steer complex simulations and optimizations.

Yet in this age of Internet of Things (IoT) enabled products, there’s a new discipline has come your way: embedded system design—now front and center in nearly every kind of product. While it’s not essential to become a master embedded system developer, experts say mainstream engineers are going to require a general understanding of software design, and most importantly, move their attention beyond traditional mechanical or electrical silos to take a more holistic view of product design.

“The challenge today is the disconnection between the different disciplines,” says Allen Watson, product marketing manager for Design Ware ARC Tools, OS and Ecosystem at Synopsys. “In the past, you’d have the guys doing hardware design completely separate from the software folks and there might be almost no communications between the two. Today’s embedded systems are so complex, you just can’t do that. You need all the different disciplines being together from the start when requirements are set.”

A Holistic View

Universally, the first rule of order for successful embedded systems design is following a systems engineering approach. This means thinking about how all of the components of a product work together as a system at the inception as opposed to retrofitting the various mechanical, electrical and software pieces together midway or later in the development cycle, explains Sudip Singh, vice president and global business unit head of engineering services at Infosys.

While systems engineering has been a staple of certain industries like aerospace for decades, it’s still not an institutionalized best practice across mainstream engineering organizations. Yet rather than a single individual redefining their skill sets to become a master at all the different disciplines, Singh says the fusion of talent needs to happen at a process and platform level.

“It doesn’t mean mechanical engineers and embedded engineers should rethink or learn a different language, it means they need to understand system engineering concepts of how a system works together upstream in the development cycle,” Singh says. “They need to get to a place where they can don’t have an embedded group or a mechanical design group, but they have an systems engineering group that houses the right people from mechanical design and embedded design as a single unit that works as one.”

Organizations embracing embedded systems design as part of a shift to IoT-enabled products also need to figure out how to infuse some of the practices of software development into their overall engineering processes. One of the biggest obstacles is getting traditional hardware engineers accustomed to the velocity of change that accompanies software development projects, notes Robyn Gold, product manager, Application Lifecycle Management (ALM) at PTC.

Model-based systems engineering tools like PTC Integrity Modeler help unify CAD, software and electrical teams with a common,
standards-based design language. Image courtesy of PTC.

“If you look at a physical product like a drive train or blender, the typical development cycle is counted in months or years from design to development,” she says. “What you see in the software world is a vastly sped up development cycle. One of the challenges is marrying the two different environments.”

Software development’s emphasis on process and compliance may also seem a bit foreign to traditional mechanical engineers, Gold says. While matching a product to a set of requirements is the gold standard in the world of hardware engineering, there’s a different interpretation in the software development space. “It’s almost more important that you have documented processes and follow them in the software world,” says Gold. “Hardware design engineers working with these software components will also need to be subject to that end-to-end process rigor.”

Another big change is the higher degree of constraints associated with embedded system design compared to traditional mechanical engineering projects. There is far less flexibility in performance characteristics, memory sizes, battery life and other such components when doing embedded systems due to much smaller form factors, according toMichael Minkevich, vice president of Technical Services at Luxoft, a software development services and IT outsourcing company.

With less flexibility in terms of trade offs and fewer degrees of freedom on optimizations, engineers need to be highly aware of how a system will be used and what the constraints are so they don’t spec a system with a touch panel, for example, when the embedded processor on board isn’t powerful enough to handle that interaction.

“Embedded software is one of the most sophisticated areas of software development in general and requires a pretty good understanding of how the entire system operates,”Minkevich says. “Engineers involved in the development of embedded software require an in-depth knowledge of the underlying hardware platform and as such, a pretty good mastery of lower-level languages like C++.”

An emphasis on debugging is another distinction that isn’t commonplace in the mechanical world, Synopsys’ Watson notes. It’s not unreasonable for software developers to spend only 20% to 30% of their time on actual design while devoting the bulk of their resources to rigorous verification and debugging practices. In order keep things running smoothly and everyone on the same page, hardware engineers need to understand the debugging process and its potential impact on project deadlines, he says.

As the two development paradigms merge as a result of more complex IoT-enabled products, most of the change boils down to a philosophical shift between hardware and software development. “With software development and embedded system development in general, people deal with the intangible—you can’t touch the code—you write so it requires a certain level of abstraction to understand how it operates,” Watson says. “When you create something with your hands, you can touch and feel it and understand how it works. This is sometimes a major obstacle from jumping from one space to another.”

Smooth Transition

Despite the philosophical and cultural challenges, there are a variety of tools and design platforms that can help break through traditional barriers and encourage systems engineering best practices. Take software coding, for example. ALM platforms and software configuration management tools like PTC’s Integrity Lifecycle Manager can help development teams manage software cycles and design reviews, maintain fine-grained version controls and handle processes for check-in and check-out, says PTC’s Gold.

Model-based systems engineering (MBSE) tools and practices can also be enlisted as a common language for communicating across disciplines. “How do you collaborate when you have one guy talking electrical diagrams and software people talking C++?” Gold asks. “Many leading companies are moving to a model-based systems engineering approach that allows all technical disciplines to understand each other and share and collaborate more easily.”

Tighter integration between tools like CAD, simulation software and platforms such as National Instruments’ (NI) LabVIEW will also help connect previously disparate engineering silos and streamline the process of creating and testing embedded system designs.

“Think about the ability to collect sensor data, push it back into the CAD tool and then change design materials to get a different reaction or put a different force on the design, then push it back into LabVIEW for testing,” says Shelley Gretlein, director of NI’s software group. “By getting rid of siloed tools, you improve communication between experts in a big way. You don’t want one tool for creating algorithms, a different tool for mechanical design and yet another for testing. You want a flexible platform for both hardware and software design that flows across all stages.”

With its graphical interface and detailed representation of both hardware and software, Synopsys MetaWare Debugger helps pinpoint errors in program code. Image courtesy of Synopsys.

PLM (product lifecycle management) is also at the forefront of fostering cross-discipline collaboration. “You’re not going to be able to sit in an office with the door closed without talking to any one any more—there have to be relationships between subsystems,” says Michael Munsey, director of Envoia Semiconductor Strategy at Dassault Systemes. “PLM is a big piece of that. It’s where you start to collaborate across all possible functions, from requirements handling to defect handling.”

Aside from the tools, it will take a commitment to continuous learning to make the leap from a traditional mechanical engineering mindset to a true multi-disciplinary, systems level point of view. “There are a variety of options depending on the level of formality, time and budget and individual might have,” says Gretlein. “But IoT is a cool catalyst for continuous learning. In the last 10 years, there hasn’t been as clear a reason to up your skill set.”

• Dassault Systemes
• Infosys
• Luxoft
• National Instruments
• PTC
• Synopsys