4 Tips to Engineer Smart Connected Products

References Cited

Electrical Computer Aided Design (ECAD), Routed Systems Design (RSD)

For some, the IoT era represents a tremendous opportunity. For others, it is a significant threat. Either way, almost every company is trying to figure out how to engineer smart connected products. You can slap some sensors on your product and start streaming terabytes of data, but that doesn’t equal success. This post provides four tips on how to start developing smart connected products faster and smoother.

Drivers: Business Goal or Educational Exploration?

This first tip has nothing to do with technology. However, it might be the most important one. Companies that are looking to engineer smart connected products fall into one of two categories. Let’s take a look at both.

First, there are some companies that have a business objective in mind that will be enabled when the connect their products to the IoT. For example, a medical device company found they couldn’t hire and train enough field service technicians to support the maintenance of their products. They connected their products to the IoT so they could transition to a predictive maintenance model. They also started using augmented reality to provide on-demand service instructions. As a result, they didn’t have to hire as many technicians. Those technicians needed less training. This was a business-driven pursuit.

Second, there are some companies that don’t yet know enough about the implications of connecting their products to the IoT. They don’t yet know what data they would be most valuable. They don’t yet know what they can do with that data. These companies simply need to start collecting some data, either in an R&D lab or from brownfield products to get oriented. There are more keys here, but that’s for another blog post.

Note that there is nothing inherently good or bad about either of these modes. Some companies are lucky enough that the application of the IoT to their products is obvious. But if you’re not one of those companies, you’ll have to go through the educational exploration mode before getting to the business-driven mode. And that’s OK.

Implementing an IoT System is Distinctly Separate

Boy oh boy, do a lot of companies get wrapped around the axle on this one. You see, there’s a misnomer that you have to develop your IoT system, which is used to collect data or operational anomalies off the product, while you are developing the product. Those two efforts, however, are distinctly separate. Why? There are a few reasons.

Think about your IoT system. It won’t just connect to a single connected product. It will connect to many of them. Over time, as your company develops new products, they each, in turn, connect to that same system. I know of one company that provides fuel systems for commercial airplanes. They’ve been downloading data from those systems to centralized servers for decades. They know what how to model their data and how to predict service issues. Essentially, their IoT system was developed long ago. As they transition forward, they’re looking at wireless means of communication instead.

The effort to engineer smart connected products is a distinctly separate effort. There you need to figure out how you are going to capture the data you need, not what data to capture. That involves selecting and placing sensors. That involves developing the electrical system with network bandwidth and power for your embedded systems. It is a very different separate task.

IoT Systems Need IT-Product Hybrid Engineers

I’ve written about this point before, but it bears repeating. Development of IoT-enabled products will require a new role in product development: the IT engineer.

You will need someone to develop and maintain your IoT system. It’s an interesting beast because it resembles an enterprise IT system. It will likely sit in the cloud somewhere. It can be tweaked and configured. It will have updates from the provider, so you’ll have to check to make sure that none of your stuff is broken. In those ways, it resembles a piece of cloud software.

However, note that it is unique in other ways. It interfaces with the electronics and software on the product. As more products are developed and launched, they will need to connect to the same system. Over time, the person responsible for the IoT system will start getting requirements that are needed to support new product development efforts. In this way, it looks, acts and feels like part of product development.

So be aware: you’ll need a new role here.

Smarts Requires Software, Software Requires Electronics

At this point, I think we all know that the smarts in smart products come from embedded software. So obviously as any company wants to engineer smart connected products, they need to have embedded software development capability.

While software is important, every developer has an electronics hardware problem. You see, electronics (sensors) is how any smart product senses the world around it and its own operation. Electronics (processors) provides the power to process that information at the required rate, sometimes in real time. Electronics (antenna) provides the ability to communicate. Those things need to be connected with cables with good signal integrity. Those things need to be placed to avoid electromagnetic interference.

As your company starts to engineer smart connected products, you’ll need both embedded software development as well as electrical and electronics design capabilities.

Summary and Takeaways

  • Figure out if your IoT effort is business-driven or more educational exploration. If the application of IoT to your business isn’t explicitly clear, then you’ll likely start with exploration.
  • Implementing an IoT system is distinctly separate from developing an IoT-enabled product. They involve two very different sets of roles and activities.
  • You’ll need a new role involved, an IT-product hybrid engineer. They can handle the dual nature of IoT systems.
  • You’ll need capabilities for embedded software development and electronics design. Don’t underestimate that part of development.

Do you have some other tips? Please share in the comments below.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.