Continuous engineering: Delivering continued value for your customers

Marketing Manager, Continuous Engineering in IoT, IBM

In a previous blog, I wrote about using continuous engineering to design and deliver a service that customers value. A key aspect of continuous service is that customers can access it as often as they want over a period of time. Ensuring customers are satisfied requires updating the service as customer needs and preferences change, which requires keeping the underlying products that support the service up to date.

Defining products in operation

Understanding how to update products that are in use is easier said than done, however, especially for products that are changed in the field due to maintenance. When products were mostly mechanical, this wasn’t a major problem, as the definition of the product could easily be updated whenever a component was replaced as part of a repair. This definition is called the “as maintained” definition, and is the most important definition for mechanical products in operation.

In fact, there are multiple definitions of the product as it progresses through its lifecycle. First, there is the “as designed” definition, which engineers create to reflect how a product should operate in theory. Then as the product is manufactured, subtle tweaks to the design may be required to facilitate assembly—the resulting definition is called “as built.” As changes occur during the product’s operational lifetime, they are reflected in the “as maintained” definition described above.

Traditionally, companies have mastered the ability to transition between each succeeding definition. But the Internet of Things (IoT) and continuous service delivery are exposing a huge problem with how things have been done. Specifically, as engineers handed off the “as designed” definition to manufacturers to create the “as built” definition, the linkage between those two definitions was broken. Manufacturers didn’t see the need to understand the relationship between these definitions, since theirs was the only one that mattered to them. Besides, the “as designed” version had already served its purpose. This is the same story for the “as built” to “as maintained” transition.

The problem with breaking these linkages is that it makes product improvement much more difficult. If a problem with a product occurs in the field, it’s nearly impossible for an engineer to examine the problem from a design perspective, since the “as designed” definition used was never updated to reflect the “as maintained” definition used in operations.

Addressing IoT-related software updates infusion of software to deliver functionality in today’s IoT products compounds this issue. It’s increasingly difficult for an engineer to know which specific software is running on a product in the field. When a problem occurs, it’s often due to a software bug, but without an ability to understand the software configuration used in the field, it’s impossible or software engineers to replicate (and thus fix) the problem. If software in the field can’t be understood, then it can’t be updated—when this happens, the service a company delivers is good only until there’s a problem, and then it becomes immediately obsolete.

A good example of a software-updated product is a smartphone. Phone makers get around this problem by prohibiting any field changes and carefully controlling both hardware and software updates; thus, the software on the phone is in the same configuration as originally engineered, the “as designed” definition. In other less-vertically controlled industries, enforcing this level of control is prohibitive.

As an aside, an exception to this level of control is illustrated by Tesla. Rather than outsource design and manufacturing and operations like most automakers and aerospace companies, Tesla performs those operations in-house using its own tools, and so can enforce and maintain the linkage between “as designed” and “as maintained.” This allows them to perform dynamic software updates to their cars to continually extend and improve functionality over a long period of time.

Linking product definitions with product lifecycles

For all the other companies that can’t update software in the field because they don’t know what software is on what product, there is hope. IBM is working with Business Partner Aras to develop a capability to link the various product definitions associated with a product lifecycle. This will allow the “as designed” definition to be updated whenever there is a product change as a result of a manufacturing or maintenance need.

Furthermore, as analytics provides insight not only for predictive maintenance but for product improvement, engineers can understand the exact configuration of each product in operation, allowing them to debug problems faster, devise improved designs and deliver software updates with confidence.

This partnership between IBM and Aras uniquely delivers a capability that was once thought unattainable. Companies have devised internal strategies to deal with managing changes to product definitions, but the proliferation of software has left many companies struggling—and hoping software bugs don’t result in loss of life. The IBM/Aras capability opens the doors to the true potential of the IoT to support the ultimate objective—value delivery.

IBM and Aras will be demonstrating their joint capability at the IBM Continuous Engineering IoT conference, to be held in Chantilly, VA on 3–4 November.