Peter Thorne, Director, Cambashi

There are new ways of interacting with connected products. Why build instrumentation and controls into machines if every user will have a tablet or phone? Just run an app to see the displays and buttons, and operate the machine. Manufacturers will change their approach to development, operations and service.

Smartphones as controllers

I remember feeling mildly alarmed during a 2012 research interview with a medical equipment designer. At that time, her main project was to estimate the potential cost savings of using the electronics and display of smart phones as part of the control system. The idea was for every user to dock their phone into the equipment.

The design study was looking at user identification, login, and privacy. My instant reaction was hygiene – this is medical equipment, are those phones clean? And what about the operating theatre – would there be enough staff with phones to operate all the machines? Then the security gorilla reared its head – how could anyone be confident the phones were free of malware?

Then also in 2012, I first became aware of Ecomove’s Qbeak[1]electric vehicle design. At that time, it used a similar concept.

The driver docks their phone into the car, and the phone becomes the instrument cluster, sat-nav, and the infotainment system. I don’t remember feeling alarmed by the Qbeak. It’s a few years ago, but I imagine this means the phone did not control the brakes or steering!

New IOT interaction with products

The growth of technologies around the Internet of Things has made these kind of ideas just one part of a whole host of new ways of interacting with all kinds of products.

Let’s try and break that statement down.

Communication with a connected-product can be both ways – in and out. The communication can be with the product itself, and with its digital twin, and with some variation of the digital twin or its environment – to try out ‘what-if’ scenarios.

Cloud-connected products can be accessed from any Internet access point.

The interaction can include any or all of the sensor readings and control settings. Data sources and systems external to the product can be fed into the interaction. For example:

–in a production machine, visibility of customer orders helps

–for agricultural machines, crop yield histories help farmers to optimize their fertilizer application.

–product sensor readings and cloud-based analytics enable predictive maintenance – the technician arrives with the right spare part just before the problem results in unplanned downtime

So who needs those dials and switches?

One question, though.

If remote control is possible, then what’s the point in having connected product with displays and instruments for local control? Why not remove these expensive components?

The connectivity will allow any authorized user with the right app on their phone or tablet to stand beside the machine – or indeed, anywhere on the planet – and use the app to check readings and adjust controls.

And the software that provides this capability may offer more than you expect – for example, review of recent control inputs and sensor readings.

Add a touch of augmented reality

Augmented reality (AR) technologies add information to a live video of a product. The video feed could come from:

–a camera built-in to the machine

–a camera installed so that is has a view of several machines

–the camera on an operator’s phone or tablet

The value comes from breakthroughs. For example, the ability to display an X-ray of the product, which can be used to highlight faulty components.

In some use-cases, there’s not even any need for the product itself! Why should a distributor tie up capital in a showroom full of machines? Why not markers in place of the machines, and an AR application that provides a viewport for your customers to walk around and study a detailed product image from all angles?

Since it’s AR, they could see alternative options and configurations, and call up specifications all at the touch of a button (or screen).

The need to change development, operations, and service

With barriers of distance and location eliminated, people, other machines, and external systems can observe a connected product (and its digital twin) and respond in new ways.

If you’re involved in product development for machinery, you’ve been thinking about these possibilities for some time. Your priority is probably new product function, and better service options. And, of course, the cost reduction pressure is always there.

Obviously, you know what your machines are used for, but this new environment means you need more insight across the whole product lifecycle.

What could your machine do to make itself easier to make, test, buy, configure, install, learn-to-use, and operate?

Your firm has probably run many initiatives focused on the design-to-manufacturing interface, from early days of developing the manufacturing concept, to creating the process, ramping up to volume, and managing the continuous change to handle manufacturing and field feedback.

So the product development process is probably multi-disciplinary, bringing development, manufacturing (and perhaps even service engineers) together to improve decision-making by taking a broad view of the requirements.

Of course, when you remove the switches and displays from your machine, you are making some of your manufacturing colleagues’ tasks simpler – fewer parts, fewer display, switch and button cut-outs in the exterior panels … so generally simpler production.

…and rewrite existing business models

But this view is just the beginning.

Taking the visible controls and displays away from a product is a great way of triggering the question “…so who is monitoring and controlling this machine?”

This is where your engineering initiative can help develop your organization’s business model.

The new control concept makes it easy to see that your company, or a third party, could manage and control the product – for example, from a central service center. Your organization could use possibilities to move from selling products, to selling the use – or even outcomes – of using these products.

The scope gets bigger, again

Removing product switches and displays makes some things simpler, but not enough to turn the tide of growing complexity.

Handling the shift to a smart product is tough because of the multiple technologies involved: mechanical, electrical, electronic and software.

Trade-off decisions are now even more complex, so much so that a systems-engineering discipline may be needed to avoid a committee vote for every decision!

A smart connected product, sold with operation or service agreements, means much stronger connection of the engineering team to the product in operation.

Instead of being largely isolated in the old ‘development’ and ‘production’ parts of the organization, data streams from the product provide a high fidelity view of the product in operation.

This will help calibrate simulations. The new service team will be fiercer than any customer in feedback of any problems.

New life in the field

Product function and performance depends on all its components (including the software), as well as the capabilities of the connected back-end systems.

So, development engineers (and, of course, the sales and marketing teams) have a new method of providing new capabilities – update the software (and remember to update the as-maintained records).

Caught in the dataflows?

It is easy to imagine engineering teams getting caught out by the volume, frequency, scope and detail of even these new dataflows, and we haven’t even mentioned software configuration and support for resellers wanting to demonstrate the new capabilities, or coordinating a new software baseline with production and test.

Fortunately, for most design and manufacturing organizations, this is familiar territory, given that engineering dataflows and processes have been getting more and more complicated for decades, for a range of reasons including: distributed development teams, global supply chains, and gaining regulatory approvals.

Software from the Product Lifecycle Management (PLM) stable provides the tools needed to manage data, and manage workflows. PLM has the structures needed to handle the new dataflows.

The new engineering software battlegrounds

The transition of smart connected products from the special case (NASA has been building smart connected products for decades) to more widespread adoption is a shift in the tectonic plates of the engineering software landscape.

Handling new dataflows is just one example, but there are loads of other opportunities for competing engineering software vendors to gain an edge over their rivals.

Think of:

Agile systems definition: Agile methods are established in software development, and include characteristics that would be described as “just good engineering” by traditionalists and hardware developers. But few tools for agile software development offer the visibility and control needed for exchange of complex requirements databases between customer and a complex supply chain.

Configuration management, product line engineering and platform architectures all offer partial answers, but smart connected products will create demand for new agile systems definition tools to support concept and early stage architecture development, capable of driving consistent use of the many early stage simulations product architects will need.

ALM or PLM or both? In software development, Application Lifecycle Management (ALM) tools play the role that PLM plays for the physical parts of a product. So how can integrated software/hardware teams manage their work? There are several ways of answering this question.

One is to separate out ‘management’ of everything into a higher level function that supports access control, versions, workflows, baselines, variants, dependencies … everything excluding the content of the object being managed. Others compete with this concept by creating integrated environments – the Integrated Development Environment (IDE) used in software development is an example – in which authoring and test tools are included, so the result manages the content as well as the status of the managed objects. Our research interviews have indicated that engineering managers feel that ‘software is different,’ yet still expect PLM vendors to take the lead on how to configure tools for integrated hardware/software development.

The BoM boundaries. When talking about product definition, the problem has always been “Which Bill?” As designed, as planned, as manufactured, as installed, as maintained – they all have a claim.

This situation has been a traditional battle ground between PLM providers and ERP providers. PLM has been secure in control of the engineering parts list. The battle starts as this is translated into the as designed bill of materials. For many companies, this is where ERP takes over, and becomes of the owner of the BoM (bill of materials) used for production scheduling, including all the handling of alternate parts. Similarly, PLM has control of development of the manufacturing process, and the manufacturing process plan for each product, sometimes called the ‘Bill-of-Process.” But ERP providers can get involved as this gets translated into shop floor documentation and electronic work instructions. Adding embedded software as a component of the product will disrupt this battle.

Service and Over-the-Air update: Most service organizations will want to make sure that engineering has no more than read-only access to products in the field. Similarly, service organizations will want control over the applications that handle data (especially alarms) from in-service products.

The service organization will want their process of escalation and adherence to service-level-agreements, to take priority over engineering’s desire to identify root causes. This is a new and interesting area, because PLM systems already contain all the configuration dependencies. Could PLM be extended so that these dependencies can drive service decisions in the field? Or does service need to own an as-maintained BoM and configurator rules?

Test management: Some design methods start with ‘how can this capability be tested.’ It is also possible to parameterise tests, and link these parameters to product parameters – so the final choice of the product parameter in effect generates the test specification:

–Will these concepts help manage and automate test creation and execution for smart products?

–To what extent will the tests on software that allow the master version to be released to manufacturing need to be supplemented with further tests once the software is loaded onto the smart product?

–Will the simulation environments used during product development define the external operating conditions or the response of the product in a way that allows re-use in testing?

Simulation. Embedded software is critical to smart product performance. Simulation technologies have grown to handle multi-physics and interconnected sub-systems, software is a new technology to handle.

The simulation battle ground for engineering software vendors is active on many fronts, including:

–simulation data management

–the practicality of flexible ways of enabling hardware (and software) “-in-the-loop” as the various prototypes of electronics, sensors, actuators become available

–the feedback of actual test and product performance to calibrate and improve simulation models, enabling simulation at an early stage in development

–making simulation accessible to a wider range of engineers

In addition, as the role of the digital twin of a product becomes larger, there will be more demand for simulation to support product operation decisions.

Getting used to a product with no visible means of control is just the start. Security, Internet access, the likely need to replace controllers with new generations of electronics during the lifetime of a machine, these are just some of the new factors for product developers to think about.

As with previous technologies, engineering processes and dataflows will adapt.

For PLM vendors with ALM capability, this is a time of opportunity – the information their technology holds about a product now has even more value in manufacturing, as well as for operation and maintenance.

But ERP vendors will point out that their systems help match processes to costs, and that is often the message budget holders want to hear.

Cambashi
Cambashi.com

[1] Qbeak is now being used as the starting point for a European consortium research project called ‘Behicle’ – BEst in class veHICLE, see http://behicle.eu/ .

---

Filed Under: Design World articles, IoT • IIoT • internet of things • Industry 4.0

 

---