General Engineering Principles

1. Introduction
• An introduction to general engineering
principles would be beneficial for any
engineering design.
• These principles and concepts apply to any
engineering system, and following them and
taking them into consideration is critical to the
success of any engineer.
 2. Engineering Principles
• There are a number of general engineering
principles that can be usefully applied during
design and testing.
 1. Do not re-invent the wheel:
There is no point in trying to re-design subcomponents of
the system you are designing.

For example, if you are building a motion control system

and need a speed feedback device, it is much better to
buy a ready-made one than try to build or design one
yourself.

You can then concentrate your efforts on adding value

and enhancing the whole system, rather than spending
time on working out the details of the subcomponents
 2. “Everything should be made as
simple as possible, but no simpler“:
• A design should always be kept as simple as
possible.
• The simpler the design the easier it is to
troubleshoot it, and the more reliable it is.
 3. Always check your hypothesis (do
not just make assumptions):
Follow the scientific method, which comprises the following steps:
a. Observe the system (for example if you are trying to locate a fault, or
understand how the system works).

b. Formulate a hypothesis that explains what you are observing (for

example, you might decide that the reason for the system not
working is the absence of a power supply voltage, or a failed
component).
c. Carry out an experiment that will test the hypothesis.

d. If the result of the experiment confirms your hypothesis, then the

hypothesis becomes a theory.

e. If not, then the hypothesis is incorrect and you need to go back to step 2
above, formulate a new hypothesis and test again.
Flowchart of the Scientific Method

Following the Scientific

Method saves time,
effort and money.
 4. Problems in real life are not very
clearly formulated:
• When facing a problem in real life, it is worth
spending some time understanding what the
problem exactly is.
• Before attempting to solve a problem, it is
very important to understand what that
problem is and to state it in clear terms.
• This is half the solution.
 5. Cost versus performance:
• Most engineering decisions are a compromise
between cost and system performance.
• Depending on each application, the Engineer has
to make a decision as to what performance is
needed against the cost of the system.
• In certain applications, the lower performance
from a cheaper system might be acceptable.
• The Concorde plane is a typical example: it was a feat of
engineering, but was so expensive that in effect it was
economic failure!
 6. The cost of errors grows exponentially
as the design progresses:
• It is always important to check the design as
early as possible.
• As the design progresses the cost of
correcting an error grows exponentially.
• Time spent early on in the design process can
save a lot of unnecessary costs later on.
 7 Piecewise Testing/Building and
Successive Refinement:
• Building and testing a system in a staged approach is
much more manageable and easier than trying to build
it and test it all in one step.
• The system should be broken down into logical sub-
systems. Each sub-system can then be built and tested
separately, before putting all the parts together.
• This concept of piecewise testing is very widely used in
software development.
• Moreover, for each subsystem its first design can be
made as simple as possible, and then further
improvements can be added; this is termed successive
refinement.
 A system that comprises 4 subsystems.

When building such a system, it is logical to build sub-system 1 first and test it
by injecting signal A and looking for signal B. Then building subsystem 2 and
injecting signal B and looking signal C and so on.
When testing such a system, we would first inject signal A and examine signal E.
If E is missing or incorrect, then we would look for signal C. If signal C is correct,
then we would look for signal D. If Signal D is incorrect, then we know sub-
system 3 is faulty….and so on.
 8. Design for faults (fault tolerant
designs):
• We cannot assume that systems will always function in
the way we intended them to.
• Components can and do fail after a period of time (or
a number of operations). It is thus the duty of the
designer to check that the system can still operate (or
at least remain safe) if a component fails.
• The engineer is faced with two design options when
one or more component fails: Either shut the system
down or design it such that it can still run with a
certain number of failed components (redundancy and
diversity).
 9. Help the trouble-shooter:
• The designer can make the system easier to
trouble-shoot and find the fault by placing
suitable test points at which the trouble-
shooter can check.
• It is also possible to provide visual/audible
feedback on the status of certain signals or
functions (e.g., place a special LED or lamp to
show whether a certain signal is high or low).
 10. Redundancy and/or diversity:
• In order to protect against component failures, it is advisable that
redundancy be included in the design.
• Redundancy is the duplication of the same function using the same
technology.
• For example, using two processors in parallel to carry out the same
function. If one processor fails, then the other processor carries on
the function, without loss of system operation.
However, some ‘common modes of failure’ will affect both
processors. So diversity can be used to protect against common
modes of failure (CMF).
• Diversity is the duplication of the same function using different
technologies. So rather than using two processors in parallel, we
• could use a processor in parallel with hardwired logic so as to
implement the same function.
 11. Think of maintenance and whole
life cost:
• When designing a system, it is important to think of how it
is going to be maintained. Ask yourself the following
questions:
• a. It is easy to access for cleaning? Is it safe to access for
cleaning?
• b. Can it be misused2? Can it be abused? Will that
endanger users?
• c. If a certain part needs regular replacement, is it plugged
into a socket? Or does it need solder removal?
• d. Can any risk be removed at design stage?
• e. How much will it cost to maintain?
• f. How much energy will it consume over its lifetime?
 12. Common sense:
• Common sense is not as common as we think.
When you get an answer to a calculation you
have carried out, check that it makes sense?
• Relative humidity cannot have a negative
value or a value in excess of 100%.
• It is unlikely that a thickness of a sheet of steel
is more than 10 mm.
 13. The Pareto principle (or the 80-20
rule):
• “The Pareto principle (also known as the 80-20
rule) states that, for many events, 80% of the
effects come from 20% of the causes”
• This can be applied in many engineering
applications and in quality control.
For example 80% of the failures might come from
20% of the components.
• It has practical applications when trying to
improve the design of a system or raise the
quality.
14. Safety factors and safety margins:
• During the design process, it is usual to use safety factors to
increase the size of a component for example. This is done in order
to account for unexpected changes due to the one of the following:
• a. Change in the working conditions (e.g., increase the load
expected load on a structure; overload on a motor; increase in the
ambient temperature for electronic components).
• b. Variation in the manufacturing parameters of the components
used (e.g., due to imperfections in the manufacturing process, the
tensile strength of a steel rod might be less than the quoted value).
• c. Wear and deterioration in the condition of components over life
or lack of proper maintenance (e.g., corrosion in a steel structure;
reduction in the efficiency of a cooling system due to dust clogging
up the filters due to bad maintenance).
 15. What does the client want?
• It is very important to understand what your
client wants.
• This is usually formulated in terms of a user
requirements specification (URS).
• This is very critical, as you might be spending
thousands of hours and vast amounts of
resources designing a system that is very
complicated, when the client actually needs a
system that is much simpler, all because you
misunderstood what the client actually wants.
 16. Concentrate on functionality and
not design:
• When starting to design you need to carefully
think of what the product should do, not what
is should be made of or how it should be
designed.
• Design comes second. It is most important to
clearly state what the system will do. The
design comes out of that.
17. Aesthetics as well as functionality:
• In designing a certain product it is
recommended that the product be made
beautiful as well as functional.
• This enhances the value and the success of
the product in the marketplace.