My last blog post on prescriptive engineering describes a view that is admittedly aspirational, but having been recently inspired by work done by IBM Institute for Business Value (IBV), I’m ready to move even further “out there”. The IBM IBV report I reference describes the stages of evolution of IoT with corresponding levels of device intelligence.

The convergence of IoT maturity and device intelligence

I outlined prescriptive engineering as the ability to use IBM Watson to model the correlation between business results and operational characteristics resulting from a product design such that engineers can be informed to make design decisions that will positively impact business results. Watson would accomplish this by doing what it does best—digesting tons of data captured within IoT to net out trends and conclusions.

Cognitive engineering

But let’s go one step further—to cognitive engineering. So what does cognitive engineering mean?

The IBM IBV report states that “Cognitive IoT, much like a human, learns about a system and creates a model. It then reasons with this model to find the inputs to the system that will optimize its outcomes.”

 Cognitive IoT is about changing outcomes

Using this definition, cognitive engineering would mean learning about the effects of various product development alternatives to create a model—a “digital twin” of your development function and its impact on your business—and then optimizing product design for specific business results.

A digital twin of the engineering function

In cognitive engineering, Watson is basically modeling, forming a digital twin of, the engineering function! Ok, why not? We’re just exploring possibilities here. Let’s think about it…

At IBM, we’ve already been able to use Watson to gain insights into product lifecycle data. Think, for example, of cognitive requirements, where you could use Watson to detect anomalies in requirements definitions—where we might have duplicate or conflicting requirements. It’s not such a stretch to ask Watson to optimize requirements based on what it already knows, having modeled business results against design alternatives.

Within our suite of connected product development software at IBM, we have a reasonable level of automation for using requirements to generate systems models. Similarly, we have automation for generating software from those models. With automatic traceability between requirements and tests, we have guidance for the specific tests that should be run.

So perhaps it’s in the realm of possibility to automate this process? Ok, I’m not proposing that we will replace engineers with machines anytime soon, but the concept of cognitive engineering could certainly help engineers increase efficiency by working faster, increase innovation by exploring more design alternatives, and most importantly, deliver designs that produce better business results.

I’m certainly interested in your feedback and thoughts on these possibilities. To learn more about existing capabilities of IBM software for connected product development, please visit www.ibm.com/continuousengineering.

This article was originally posted on LinkedIn.