Page 53 - The Mechatronics Handbook

Systems Engineering

Electrical Mechanical
Engineering Engineering

Software
Engineering

FIGURE 3.10 Mechatronics engineering disciplines.

3.8 Software Control

Systems Engineering
Systems engineering is the systems approach to the design and development of products and systems. As
shown in Fig. 3.10, a drawing that shows the relationships of the major engineering competencies with
mechatronics, the systems engineering competency encompasses the mechanical, electrical, and software
competencies. There are several important tasks for the systems engineers to perform, starting with
requirements gathering and continuing through final product and system verification and validation.
After requirements gathering and analysis, the systems engineers should partition requirements func-
tionality between mechanical, electrical, and software components, in consultation with the three
competencies involved. This is part of the implementation of concurrent engineering. As also shown
by the figure, software is an equal partner in the development of a mechatronic system. It is not an
add-on to the system and it is not free, the two opinions that were sometimes held in the past by
engineering management. While the phrase “Hardware adds cost, software adds value” is not entirely
true either, sometimes software engineers felt that their competency was not given equal weight with
the traditional engineering disciplines. And one last comment—many mechatronic systems are safety
related, such as an air bag system in a car. It is as important for the software to be as fault tolerant as
the hardware.

Software Engineering

Software engineering is concerned with both the final mechatronic “product” and the mechatronic
development process. Two basic approaches are used with process, with many variations upon these
approaches. One is called the “waterfall” method, where the process moves (falls) from one phase to
another (e.g., analysis to design) with checkpoints along the way. The other method, the “spiral” approach,
is often used when the requirements are not as well fixed. In this method there is prototyping, where the
customers and/or systems engineers refine requirements as more information about the system becomes
known. In either approach, once the requirements for the software portion of the mechatronic system
are documented, the software engineers should further partition functionality as part of software design.
Metrics as to development time, development cost, memory usage, and throughput should also be
projected and recorded. Here is where the Software Engineering Institute’s Capability Maturity Model
(SEI CMM) levels can be used for guidance. It is a truism that software is almost never developed as
easily as estimated, and that a system can remain at the “90% complete” level for most of the development
life cycle. The first solution attempted to solve this problem is often assigning more software engineers
onto the project. This does not always work, however, because of the learning curve of the new people,
as stated by Frederick Brooks in his important book The Mythical Man Month (Addison-Wesley 1995).

©2002 CRC Press LLC