To improve the design of consumer goods and industrial motion setups, engineers have embraced mechatronics — but have had to develop techniques to deliver on its promises of flexibility and performance.
Mechatronics in engineered machinery — combining mechanical parts and actuators with hybrid electronic and computer-based controls — is the original inspiration of modern-day connectivity. Three considerations are pertinent to today’s integration of mechatronic functionality into designs.
• Unifying technical disciplines complicates organizational structures and standards. Mechatronics engineers push the boundaries of existing tools — mechanical CAD, electronic design automation, software development, stress analysis, and kinematic analysis — which all have their roots in single technologies. Therefore, while solving problems of machine integration, designers have also had to solve problems of development-tool integration.
More on Mechatronics:
PMMI Mechatronics Certificate program
The mechatronics-Lego connection and The mechatronics-Da Vinci connection
From the archives: Early mechatronic developments
• For any mechatronic design, the engineer must decide on what’s called the network interface boundary. An increasing number of devices “phone home” for software updates. For example, some medical imagers use a connected service for archiving; certain jet engines transmit sensor readings to service desks for in-flight monitoring and analysis; a number of consumer electronics stream cloud-based music and images; and sophisticated agricultural machines regulate fertilizer concentrations according to GPS location and historical records of yield. These and other mechatronic designs have proliferated because of the low cost and wide availability of network connectivity. However, for every device connected to a network, designers must decide on a suitable division between local device functions and remotely accessed functions — what’s called the network interface boundary — as it impacts in-service performance.
• Connectivity broadens the list of component features to be compared. Consider that some industrial machines incorporating controllers with a network interface and embedded software send machine status information to (and accept control parameters from) a webpage — useful for remote monitoring and control. With a bit more embedded software in the controller, information can also be sent to the end user’s corporate asset management system. This data can be used to automate maintenance and replace traditional interval-based servicing with as-needed adjustments. Here, an OEM can use embedded software to reduce total machine-life costs, expanding the basis of competition beyond machine requirements for precision, power consumption, and flexibility.
Expanding component features
Embedded software continues to advance subcomponents as well, including next-generation touchscreens, cameras, microphones, GPS, and motion sensors normally considered commodities. Embedded software coordinates their functions for more sophisticated operations.
Actuators are also becoming increasingly mechatronic — suggesting a future in which machines of all types are built from low-cost standard mechatronic subsystems assembled around platform architectures or frameworks, and integrated by embedded software loaded into the platform. In this setup, individual product lines depend on the platform’s scope; differentiation depends on the capability of the embedded software. In fact, the automotive industry has been moving towards this structure for years.
Restructuring the design process
Engineering management teams looking to leverage software to differentiate their products from the competition sometimes face culture shock. The widespread visibility of apps in the consumer world has helped to demystify the intangible nature of executable files. However, complex build structures of source code, interactions between multiple software objects, malware threats, and the need for software engineers to handle changes at rates 10 to 100 times faster than mechanical components requires some design-approach adjustments.
These engineering management teams need methods that provide visibility, a framework for multidisciplinary creativity, abolition of artificial boundaries between technology disciplines, and toolsets for the disciplines they handle.
One such methodology is based on the V-model, a central pillar of systems engineering. By specifying a mid-project phase, which turns the V-model into a W-model, its authors address the issue of dependencies between multiple technologies. One caveat: The data management systems must be able to analyze and synchronize discipline-specific data across multiple disciplines. Product-development software vendors recognize this challenge, and most offer programs that allow engineering managers to choose any starting point — mechanical CAD, engineering analysis, software development, electronic design, and even product-lifecycle management (PLM) modules within enterprise resource planning (ERP) software. Many vendors even supply roadmaps for multi-domain development, modeling, and data management.
Software included with hardware: Ensure compatibility
Traditional engineering concepts apply to embedded software in mechatronic devices — including the decision to make or buy. Software components for embedded systems, including underlying real-time operating systems and device interfaces, as well as signal processing, physics, and user-interface libraries, are proliferating.
Most engineers prefer to specify commodity hardware that comes complete with a software stack. Why? This approach helps them avoid the effort of writing code to interface with the component, and focus their software development efforts on machine functions.
That said, purchased software can yield surprises. Does the software stack for a network interface handle security requirements? If controller memory speed is changed, will the camera interface stack still work? Will all purchased software modules coexist and function correctly in the single software address-space being used? It’s no surprise that with software integrated into the product, the outcomes of a design review meeting multiply.
So: Mechatronics has its origins in manufacturing; now, software is everywhere, and products in every industry depend on successful integration of mechanisms, sensors, actuators, interfaces, and software. The message to designers, engineers, and their managers is loud and clear: Skills in individual disciplines are essential, as are skills and tools that tear down walls between technologies. Teams comfortable with moving functions between technologies as they develop a design proposal enjoy a less constrained solution space — boosting the odds of assembling an optimal solution.