Connectivity and the new face of machinery
December 30, 2016
There are new ways of interacting with connected products. Why build instrumentation and controls into machines if every user will have a tablet or ph...
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.
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 smartphones 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?”
Also in 2012, I first became aware of Ecomove’s Qbeak electric vehicle design. Qbeak is now being used as the starting point for a European consortium research project called Behicle, for BEst in class veHICLE. The driver docks his phone into the car and the phone becomes the instrument cluster, sat-nav, and infotainment system. I don’t remember feeling alarmed by the Qbeak; as this was a few years ago, I imagine this means the phone did not control the brakes or steering.
IoT interaction with products
The growth of technologies around the Internet of Things (IoT) has made these kinds of ideas just one part of a whole host of new ways to interact with all kinds of products. Let’s try and break that down.
Communication with a connected product can be two ways, namely in and out. Communication can be with the product itself, and/or with its digital twin, and/or with some variation of the digital twin or its environment.
Cloud-connected products can be accessed from any Internet access point. Interaction can include any or all 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
- For agricultural machines, crop yield histories help farmers optimize fertilizer application
- Product sensor readings and cloud-based analytics enable predictive maintenance; technicians arrive with the right spare part just before the problem results in unplanned downtime
However, if remote control is possible, then what’s the point in having a connected product with displays and instruments for local control? Why not remove these expensive components? Connectivity will allow any authorized user with the right app on their phone or tablet to stand beside the machine (or 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’d expect. For example, it could provide a 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 into the machine
- A camera installed so that is has a view of several machines
- A camera on an operator’s phone or tablet
The value of AR comes from breakthroughs like 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 use 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, better service options, and, of course, cost reduction.
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 continuous change to handle manufacturing and field feedback. So the product development process is probably multi-disciplinary, bringing development and 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’re making some of your manufacturing colleagues’ tasks easier and reducing parts and displays, switch and button cut-outs in exterior panels, and generally simplifying production.
But this view is just the beginning. Taking the visible controls and displays away from a product is a great way to trigger the question, “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 own company, or a third party, could manage and control the product, possibly from a central service center. Your organization could move from selling products to selling the use – or even outcomes – of 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 transition to a smart product is tough because of the multiple technologies involved, which include 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. Instead of being largely isolated in the old development and production parts of the organization (as shown in Figure 1), data streams from the product provide a high-fidelity view of the product in operation. This will help calibrate simulations, and the new service team will be faster than any customer in feedback on any problems.
[Figure 1 | Changing engineering data flows.]
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. Development engineers (and, of course, the sales and marketing teams) have a new method of providing new capabilities by updating software (and remembering to update the as-maintained records).
It’s easy to imagine engineering teams getting caught up in the volume, frequency, scope, and detail of these new data flows, and we haven’t even mentioned software configuration and support for resellers wanting to demonstrate 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 data flows and processes have been getting 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 has provided the tools and structures needed to manage new workflows and data flows.
The new engineering software battleground
The transition of smart connected products from “special cases” (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 data flows is just one example, but there are loads of other opportunities for competing engineering software vendors to gain an edge over their rivals.
Here are some technologies, methodologies, etc., that you should be considering:
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 the exchange of complex requirements databases between customers and complex supply chains.
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 in support of concept and early stage architecture development that are capable of driving consistent use of the many early-stage simulations product architects will need.
ALM, 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 hardware/software teams manage their work? There are several ways to answer this question.
One is to separate out management of everything into a higher level function that supports access control, versions, workflows, baselines, variants, and dependencies, which is basically everything excluding the content of the object being managed. Others compete with this concept by creating integrated environments, like the integrated development environments (IDEs) used in software development that include authoring and test tools, and, as a result, manage the content as well as the status of the managed objects. Research indicates that engineering managers feel that “software is different” but still expect PLM vendors to take the lead on how to configure tools for integrated hardware/software development.
BoM boundaries
When talking about product definition, the problem has always been that it’s hard to understand where the billing lies as a product is designed, planned, manufactured, installed, and maintained. This has been a traditional battleground between PLM providers and enterprise resource planning (ERP) providers.
PLM has always been securely in control of the engineering parts list. The battle starts as this is translated into the bill of materials (BoM). For many companies, this is where ERP takes over and becomes owner of the BOM used for production scheduling, including all handling of alternate parts. Similarly, PLM has control over manufacturing process development and the manufacturing process plan for each product, which is sometimes referred to as the “bill of process.” But ERP providers get involved as this is translates 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 (OTA) updates
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 (SLAs) to take priority over engineering’s desire to identify root causes. This is a new and interesting area, because PLM systems already contain all of these configuration dependencies. Could PLM be extended so that these dependencies can drive service decisions in the field? Or, do service organizations need their own as-maintained BoM and configuration rules?
Test management
Some design methods start with, “How can this capability be tested?” It’s also possible to parameterise tests and link these parameters to product parameters so that the final product parameter choice in effect generates the test specification:
- Will these concepts help manage and automate test creation and execution for smart products?
- To what extent will software testing that allows 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 simulation environments used during product development define the external operating conditions or the response of the product in a way that allows reuse in testing?
Simulation
Embedded software is critical to smart product performance. Simulation technologies have grown to handle multi-physics and interconnected subsystems as software has become the new primary technology. The simulation battleground for engineering software vendors is active on many fronts, including:
- Simulation data management
- The practicality of flexible ways to enable hardware (and software) in-the-loop testing as various prototypes of electronics, sensors, and actuators become available
- Feedback of actual test and product performance to calibrate and improve simulation models, enabling simulation at an early development stage
- Making simulation accessible to a wider range of engineers
In addition, as the role of a product’s digital twin 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, and the likely need to replace controllers with new generations of electronics during the lifetime of a machine are just some of the new factors for product developers to think about. As with previous new technologies, engineering processes and data flows 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 operations and maintenance. But ERP vendors will point out that their systems help match processes to costs, and that’s often the message budget holders want to hear.
Cambashi
