It all started with mechatronics

The word “mechatronics”
successfully highlights the importance of robotics systems that
combine mechanical parts, actuators, and hybrid
electronic/computer-based controls. But now, across discrete
industries, more and more products include a heart of software.
Designers and engineers working on products from consumer goods to
industrial machines find themselves doing mechatronics, and must
find better ways to use design tools, and better ways to handle
multi-disciplinary projects.

Today, the scope of the mechatronics problem and
opportunity is growing explosively because of the low cost and easy
availability of network connectivity. Every device has potential to
be connected to the network, so designers have to consider the
relative merits of all possible divisions of function between the
“local” device and “remote”
capabilities accessed via the network.

There are examples in every sector —
more products that phone home for software updates, medical imaging
devices that use a connected service for archiving, jet engines
that transmit sensor readings to service desks the other side of
the world for in-flight monitoring and analysis, consumer
electronics devices that depend on remote sources of music and
images, agricultural machines that regulate fertilizer
concentrations according to GPS location and historical records of
yield, and many more. Design choices about which side of the
network interface will do what are critical. These choices can be a
major factor determining competitive success.

Embedded software is the technology that will
power innovation in the next generation of products. Touchscreens,
cameras, microphones, GPS, motion sensors and so on are all
increasingly available as “commodity”
components. These offer “standard” performance
that comes alive when designers find new ways of assembling them
with embedded software to coordinate their functions.

Machines of all types will be built from
low-cost standard mechatronics subsystems assembled around a
platform architecture or framework, and integrated by the embedded
software loaded into the platform (see Fig.
1). Individual product lines will depend on the scope of the
platform; differentiation will depend on the capability of the
embedded software. Indeed, the automotive sector has for many years
been moving towards this structure.

Fig. 1: Components of a mechatronics
system

In the industries that are creating
“smart” products, engineering management teams
have a sharp interest in the way their companies will handle
embedded software technology. Software development can be a bit of
a culture shock. The widespread visibility of
“apps” in the consumer world has helped
de-mystify the intangible nature of executable files. But the
relationship of these to complex build structures of source code,
the subtle effects of interaction of multiple software objects
around a network, the threat of malware, and the willingness of
software engineers to handle changes at rates ten or a hundred
times the rates you might expect for mechanical components are all
factors that take a bit of getting used to.

Engineering managers need a method or process
that provides visibility, and a framework within which
multi-disciplinary team members can be creative and efficient.
Anderl, Nattermann and Rollmann (see 1) have made a timely
contribution with a concept based on the V-model. The V-model is
widely seen as a central pillar of systems engineering (see 2). By
specifying a mid-project phase (which turns the V-model into a
W-model), Anderl et al specifically address the issue of
dependencies between the multiple technologies involved in a
project. One consequence is that data management systems must be
able to analyze and synchronize discipline-specific data across
disciplines.

Vendors of software tools for product
development recognize this challenge. Engineering managers can
choose any starting point — mechanical CAD, engineering
analysis, software development, electronic design and even the PLM
parts of ERP solutions, and vendors will offer some sort of
capability or roadmap to integrate software in a multi-domain
development, modelling and data management environment.

For example, consider tools that support systems
engineering and embedded software development. There’s
plenty to choose from in this $2.6 billion market (see 3), and some
“turbulence” as both technology and provider
boundaries change. PLM vendor PTC acquired embedded software tools
provider MKS.

Dassault bought Geensoft and extended its
requirements management and automotive software capabilities. EDA
companies such as Cadence, Mentor and Synopsys offer tools such as
system-level design, virtual prototyping and requirements
management in which embedded software is a usual component of, say,
system-on-a-chip designs.

IBM Rational offers requirements management,
systems engineering and software development tools. These IBM tools
handle software systems with components not only embedded in a
device, but also running on the computers at headquarters. They
also offer a management environment that can monitor progress and
performance indicators by direct tracking of activities across an
extended team.

Business systems providers such as SAP and
Oracle have design and manufacturing applications that are relevant
to embedded software development because they cover parts
libraries, bill of materials, version and status handling, data
access management and workflows. Oracle also offers technical
development tools for embedded systems including Java tools
specific to TV, smartcard and general embedded use.

National Instruments offers the LabVIEW system,
a way of creating embedded software (especially for test systems)
directly from diagrams. IBM’s
“Rhapsody” also builds code from diagrams,
integrating with requirements and test handling.

This is a long yet still very partial list.
Microcontroller manufacturers usually offer plugins to an
open-source, free-of-charge, development environment (almost always
Eclipse). The plugins enable the development environment to
generate code and interface to the hardware provided by the
microcontroller manufacturer. Many tools address multi-domain
simulation by interfacing to Mathworks Simulink multi-domain
simulation software.

Of course, many traditional engineering concepts
apply to embedded software in mechatronics devices. An interesting
example is make-or-buy. There is a large and growing market for
software components for use in embedded systems. Components range
from the underlying real-time operating systems and device
interfaces to libraries that handle signal processing, or physics,
or user interfaces.

For any hardware component that is seen as a
mechatronics ”commodity,” designers and
engineers prefer to specify components that come complete with a
software stack. This means they can avoid the effort of writing
software to interface to the component, and focus their software
development efforts on making the component execute functions that
represent added-value for their customers.

Mechatronics had its origins in a specific
technology area. But today’s reality is software
everywhere, and products in every sector that depend on the
successful integration of mechanisms, sensors, actuators,
interfaces and software. Teams that are comfortable moving
functions between technologies as they develop a design proposal
will search a less constrained solution space. This will give them
a better chance of coming up with an optimum way of meeting
requirements — or, at least, something better than the
competition. ■