Skip to main content
Business software? Visit Kipeo Digital ↗
HarunLucas.com
Article
Engineering ResearchPublished

What Makes an Engineering Project Research? Beyond the Laboratory

13 min read

A laboratory does not automatically make an engineering activity research, and working outside one does not prevent it. What matters is the question, uncertainty, method, evidence and knowledge produced.

Engineer reviewing simulation, sensor and machine-condition data while investigating an engineering research question outside a formal laboratory.

A laboratory does not automatically make an engineering activity research, and working outside one does not automatically make it something less.

A laboratory does not automatically make an engineering activity research. And working outside a laboratory does not automatically make it something less than research.

An engineer can spend hours using sophisticated equipment in a laboratory while following a completely known procedure whose outcome is already well established. Another engineer can sit at a computer, formulate an uncertain thermodynamic question, build a model, vary operating conditions systematically, compare the results with published evidence, document assumptions and produce new insight.

The first activity happened in a laboratory. The second may not have. Yet location alone tells us very little about which activity contains the stronger research contribution.

This distinction has become increasingly relevant in my own engineering work. I have carried out investigations outside a conventional formal laboratory using combinations of modelling, programming, literature, datasets, prototypes and practical engineering environments.

I have also increasingly noticed the difference between two activities that can look very similar from the outside:

  • Building something because the solution is already largely understood
  • Building or testing something because the answer to an engineering question is genuinely unknown

The second situation is where research begins to become much easier to identify.

What actually defines research and development?

An internationally important reference is the OECD Frascati Manual. It describes research and experimental development as creative and systematic work undertaken to increase knowledge and develop new applications of existing knowledge.

The framework identifies five important characteristics of research and development:

  • Novelty
  • Creativity
  • Uncertainty
  • Systematic activity
  • Transferability and/or reproducibility

None of these criteria says that research must take place inside a laboratory. The focus is on what the work is attempting to discover and how that investigation is conducted.

The same framework distinguishes three broad forms of research and development.

Basic research

Work undertaken primarily to gain new understanding without a particular immediate application.

Applied research

Original investigation undertaken to obtain new knowledge toward a specific practical objective.

Experimental development

Systematic work drawing on research and practical experience to produce additional knowledge directed toward creating or improving products or processes.

For engineers, applied research and experimental development are particularly important because they often sit very close to practical engineering work.

Engineering research is about knowledge, not location

Laboratories are valuable. They can provide:

  • Controlled conditions
  • Specialist equipment
  • Calibrated instrumentation
  • Repeatability
  • Environmental control
  • Safer experimental conditions

For many research questions, a laboratory is essential.

But engineering research can also involve:

  • Computational modelling
  • Numerical simulation
  • Field measurements
  • Workshops
  • Prototypes
  • Existing datasets
  • Industrial equipment
  • Design experiments
  • Documented failure investigations
  • Systematic literature analysis

The more useful question is therefore not:

“Was this performed inside a laboratory?”

It is:

“What uncertainty was being investigated?”

Building something is not automatically research

Consider an engineering-system project. The objective is:

“Build a monitoring application that collects machine temperature and displays it on a dashboard.”

The engineer might:

  • Select a sensor
  • Connect the hardware
  • Develop data acquisition
  • Store the measurements
  • Create the interface
  • Verify that the system works

This may be an excellent engineering project. It may require substantial technical skill.

But if the objective is primarily to implement an established solution using known methods, the activity is not automatically research.

Now change the question.

“How does sensor location affect the ability to detect a developing thermal abnormality under different machine operating conditions?”

The intellectual activity changes. The engineer now needs to:

  • Define measurement locations
  • Establish comparable operating conditions
  • Collect data
  • Analyse the measurements
  • Account for relevant variables
  • Evaluate differences
  • Document uncertainty
  • Compare the result with existing knowledge

The same sensor technology may be involved. But the objective has moved from building the system to learning something uncertain about the system. That distinction is fundamental.

Engineering design and engineering research overlap

Engineering design often asks:

“What should we create to satisfy these requirements and constraints?”

Engineering research asks more directly:

“What do we not yet understand well enough?”

The two are not completely separate. Suppose an engineer develops a new condition-monitoring prototype. Part of the work may involve:

  • Choosing sensors
  • Writing software
  • Developing interfaces
  • Assembling components
  • Testing operation

That is design and development.

But suppose it is genuinely uncertain whether the proposed sensing arrangement can distinguish the machine states of interest. Systematically investigating that uncertainty can become applied research or experimental development.

The boundary is therefore not prototype equals research, or prototype does not equal research. The more useful question is:

“What additional engineering knowledge is the prototype helping us produce?”

Sometimes the prototype is the research instrument

This distinction is particularly useful in engineering. Imagine developing a CNC condition-monitoring system containing:

  • Sensors
  • Data acquisition
  • Software
  • Data storage
  • Analytics

Building that system may be engineering development.

But the same system can then become a research instrument. It might be used to investigate:

  • Which signals respond meaningfully to a machine condition
  • How operating speed affects measurements
  • How sensor placement influences detection
  • Whether an algorithm remains reliable across changing operating conditions
The same prototype can serve engineering development or become the instrument for a systematic research investigation, depending on intent, method and use of evidence.

In this case, the research contribution is not necessarily:

“I built the system.”

It may instead be:

“Using this system, I generated evidence about how the machine or sensing method behaves under defined conditions.”

The artifact enabled the research. The artifact itself was not automatically the research contribution.

Uncertainty is one of the strongest indicators

One of the clearest characteristics of research is uncertainty. Compare two activities.

Activity A

Calculate a shaft diameter from known loading using an established design procedure. That is engineering analysis.

Activity B

Investigate how alternative shaft geometries behave under variable loading and determine whether a simplifying design assumption remains valid under those conditions.

The second activity contains an uncertain outcome. Research should allow the evidence to challenge the investigator's initial expectation. If the conclusion is predetermined before the work begins, the activity is closer to demonstration than genuine investigation.

A systematic method changes the character of the work

Engineers troubleshoot continuously. A technician might:

  • Change a component
  • Test the machine
  • Change another component
  • Observe the result
  • Eventually identify the fault

That can be excellent engineering practice.

Research requires something additional when the goal is to produce defensible knowledge. The investigator should make the process sufficiently systematic that another person can understand:

  • What was being investigated
  • What conditions existed
  • What changed
  • What was measured
  • How the measurements were analysed
  • What assumptions were used
  • What alternative explanations remain

A typical research structure may include:

  • Research question
  • Existing knowledge
  • Methodology
  • Variables and assumptions
  • Data collection
  • Analysis
  • Interpretation
  • Limitations
  • Conclusion

This structure does not guarantee correctness. It makes the reasoning available for scrutiny.

Can simulation count as engineering research?

Yes. But using simulation software does not automatically make an activity research.

Consider finite-element analysis. An engineer creates a known component geometry, applies established loading and calculates stress to verify whether a design meets its requirement. That is useful engineering analysis.

Now consider this question:

“How sensitive is the predicted fatigue-critical region to geometry, boundary-condition assumptions and alternative material models?”

The investigator may then systematically:

  • Define parameter ranges
  • Vary conditions
  • Compare results
  • Validate where possible
  • Document uncertainty
  • Interpret the effect of assumptions

Now simulation has become a research method. The same principle applies to:

  • Finite-element analysis
  • Computational fluid dynamics
  • Thermodynamic modelling
  • Machine dynamics
  • Energy-system optimization
  • Predictive-maintenance modelling

The software is a tool. The research comes from the question, uncertainty, method and resulting knowledge.

Can workshop and field investigations count as research?

Yes, under the same conditions.

Suppose a workshop machine repeatedly overheats. A troubleshooting objective might be:

“Find the cause and restore reliable operation.”

That is valuable engineering.

A research objective might be:

“Determine how machine load, cooling effectiveness, ambient conditions and operating duration influence the recurring thermal behaviour.”

Now the investigator could:

  • Define measurements
  • Establish operating conditions
  • Compare cases
  • Analyse temperature histories
  • Examine competing explanations
  • State limitations

The machine itself becomes the research environment. Field and workshop investigations can provide authentic operating conditions. Their challenge is often reduced experimental control. That limitation should be acknowledged rather than ignored.

Existing datasets can support original engineering research

Research does not always require collecting every measurement yourself. Existing datasets can support legitimate investigations.

A machine-condition dataset might already contain vibration measurements. A new study could still ask:

  • Which validation strategy produces the most realistic estimate of model generalization?
  • Which features remain robust across operating conditions?
  • How does class imbalance affect fault detection?
  • Can a simpler method perform comparably to a more complex model?

The dataset is not new. The research question, method and contribution may be.

What matters is that the researcher documents:

  • Data provenance
  • Suitability
  • Limitations
  • Methodology
  • Interpretation

This creates important opportunities for students and independent researchers who may not have immediate access to expensive industrial equipment.

A failed prototype can still produce research knowledge

Engineering development is frequently judged by:

“Did the system work?”

Research can still produce value when the expected result does not occur.

Suppose a proposed condition-monitoring approach repeatedly fails to distinguish two machine states. A rigorous investigation may reveal that:

  • The chosen signal is insufficiently sensitive
  • Sensor placement is unsuitable
  • Operating-condition variation dominates the fault signature
  • The original assumption was incorrect

Those findings can still contribute knowledge. An unexpected result is not automatically a failed research project. Research contains uncertainty precisely because the result is not guaranteed.

Research outside academia still requires research integrity

Independent research should not mean a lower standard. Working outside a university does not remove the need for:

  • Accurate records
  • Transparent methods
  • Correct citation
  • Honest reporting
  • Reproducible analysis where practical
  • Ethical practice
  • Safety considerations
  • Clear limitations
  • Separation between evidence and interpretation

This is especially important when publishing engineering work online. For example, claiming:

“This model accurately predicts equipment failure.”

requires strong evidence. During early development, a more responsible statement might be:

“Under the tested dataset and validation method, the model produced these results; performance under live industrial conditions remains unverified.”

The second statement makes the boundary of the evidence clear. That is part of research discipline.

Does research have to be published?

Publication is not what initially turns technical work into research. Research and development occurs in:

  • Universities
  • Businesses
  • Government organizations
  • Nonprofit institutions
  • Dedicated research organizations

Publication serves a different but extremely important role. It enables:

  • Scrutiny
  • Criticism
  • Comparison
  • Reproduction
  • Dissemination

An unpublished investigation can therefore still exhibit research characteristics. But researchers should be cautious about claiming that conclusions have been independently established when they have not yet undergone external evaluation.

Novel does not always mean never attempted before

The term novel can create unnecessary confusion. Research does not always require inventing something that has never existed anywhere.

Depending on the context, a knowledge contribution may come from:

  • Applying an established method in a new environment
  • Testing assumptions under different operating conditions
  • Systematically comparing alternative methods
  • Creating a new dataset
  • Combining previously separate approaches
  • Validating a method in a different system
  • Identifying an important limitation

The important point is that the work should seek additional knowledge rather than simply reproduce a known procedure. Specific academic programmes or journals may impose more demanding originality requirements. Those requirements should be evaluated separately.

The Engineering Research Test

A useful way to think about an engineering activity is to ask five questions. This is a practical explanatory framework informed by established R&D principles. It should not be presented as an official replacement for the OECD Frascati framework.

The more strongly an activity exhibits these five characteristics, the stronger its research character — a continuum assessed with professional judgment, not a pass/fail test.

1. What is genuinely unknown?

Do not begin with:

“I want to build a CNC application.”

Ask:

“What engineering question remains unanswered?”

2. What additional knowledge could result?

If the final conclusion is simply:

“The application now works.”

the work may primarily be implementation. If the conclusion could instead become:

“Method A becomes unreliable under these operating conditions while Method B remains stable.”

there is a clearer knowledge contribution.

3. Is there a systematic method?

Could another engineer determine:

  • What was measured
  • What changed
  • What remained controlled
  • How the analysis was conducted

4. Is the outcome genuinely uncertain?

Could the evidence realistically contradict the initial hypothesis or expectation?

5. Can another person scrutinize or build on the work?

Are the:

  • Assumptions
  • Methodology
  • Results
  • Limitations

documented sufficiently for another engineer or researcher to evaluate?

The stronger these answers become, the stronger the research characteristics of the project become.

Project, development or research?

Routine engineering, development and research sit on a continuum — classification depends on the actual question and method, not the activity type alone.
ActivityTypical classificationReason
Repairing a failed pump using known proceduresRoutine engineeringRestoration of known function
Designing a standard shaft to established requirementsEngineering designApplication of existing knowledge
Building a standard monitoring dashboardDevelopment / implementationKnown technical approach
Systematically comparing sensor positionsPotential researchInvestigates uncertain measurement performance
Running one predefined simulationEngineering analysisAnswers a specified engineering calculation
Performing a systematic parametric simulation studyPotential researchCan generate additional understanding
Building a prototypeDependsMay be routine development or experimental R&D
Analysing an existing dataset using a new research questionPotential researchCan produce additional knowledge

Potential research is used deliberately in this table. Classification depends on the actual research question and methodology being applied, not on the type of activity alone.

Examples from engineering systems

Python CNC automation

Development objective: Build software that generates CNC programs from user parameters.

Research possibility: Investigate how exposing the relationship between inputs, generated G-code and resulting toolpath behaviour influences learner understanding. The application becomes part of the research instrument.

AI predictive maintenance

Development objective: Train a model that classifies machine-condition data.

Research possibility: Investigate how different validation strategies, feature representations or operating conditions affect the reliability of the predictions. The research contribution becomes knowledge about model behaviour rather than simply possession of a trained model.

Geothermal ORC modelling

Engineering-analysis objective: Calculate the performance of a predefined Organic Rankine Cycle.

Research possibility: Systematically investigate how working-fluid properties and operating constraints interact when optimizing low-temperature geothermal utilization for electricity and useful process heat.

Again, modelling software is the tool. The research lies in the question and systematic investigation.

Independent engineering research needs external challenge

Formal academic environments naturally provide mechanisms such as:

  • Supervisors
  • Research groups
  • Seminars
  • Examiners
  • Peer reviewers

Independent researchers need to create some of that challenge deliberately. Possible approaches include:

  • Comparing methodology with peer-reviewed research
  • Asking domain experts to critique assumptions
  • Sharing methods or code where appropriate
  • Independently checking calculations
  • Presenting work to professional engineering communities
  • Submitting mature work to conferences or journals

The purpose is not merely to receive approval. It is to expose the reasoning to the possibility that something is wrong. That is valuable to research.

What should an independent engineering researcher document?

At minimum:

  • Research question — What are you trying to establish?
  • Existing knowledge — What is already known?
  • Research gap or uncertainty — What remains unanswered?
  • Method — What will be measured, modelled, simulated, tested or compared?
  • Assumptions — What simplifications are being made?
  • Data — Where does it come from, and how is it processed?
  • Results — What actually happened?
  • Interpretation — What might explain the result?
  • Limitations — What does the study not establish?
  • Next step — What evidence would strengthen or challenge the conclusion?

This documentation allows technical exploration to become work that other people can inspect and potentially build upon.

Research is not a label every engineering project needs

Routine engineering is valuable. Design is valuable. Development is valuable. Troubleshooting is valuable. Implementation is valuable. None needs to be renamed research to matter.

Research has a different objective:

“Produce additional knowledge through systematic investigation of genuine uncertainty.”

At the same time, research does not become less legitimate simply because the investigator uses:

  • Python instead of a laboratory rig
  • Simulation instead of a physical prototype
  • A workshop instead of a university laboratory
  • An existing dataset instead of newly collected measurements

The method must fit the question. The evidence must support the conclusion. The limitations must be stated. That is the important standard.

Key takeaway

If you want to know whether an engineering activity contains a genuine research component, do not begin with:

“Where was it done?”

Ask instead:

  • What is genuinely unknown?
  • What additional knowledge could result?
  • What systematic method will investigate it?
  • Could the result genuinely challenge what we expected?
  • Can the evidence and reasoning be scrutinized or reproduced?

A laboratory can provide an excellent environment for answering those questions. So can:

  • A workshop
  • An industrial facility
  • A computational model
  • A simulator
  • An existing dataset
  • A prototype

The environment affects the research conditions. It does not define the research.

“The laboratory is a research environment. It is not the definition of research.”

References and further reading

  • OECD Frascati Manual. International standard definitions and guidelines for measuring and reporting research and experimental development (R&D) activity.
  • OECD research and development guidance. Supporting OECD material on the measurement and classification of R&D.
  • NSF / NCSES — Definitions of Research and Development. U.S. National Science Foundation / National Center for Science and Engineering Statistics definitions distinguishing basic research, applied research and experimental development.
  • NSF / NCSES — R&D activity across institutional sectors. Statistics on research and development performed across academic, business, government and nonprofit organizations.
  • National Academies of Sciences, Engineering, and Medicine — engineering research guidance. Guidance on the practice and conduct of engineering research.
02Frequently Asked Questions

A few common questions

Yes. Engineering R&D occurs in academic institutions, businesses, government organizations, nonprofits and other settings. What matters is the nature and rigor of the investigation rather than institutional location alone.

Sometimes. A prototype may simply implement established technology, or it may be used to systematically resolve technical uncertainty and produce additional knowledge. The research contribution depends on the question and method.

Yes. Simulation can support research when it is used systematically to investigate an uncertain question. Running a known model for predetermined inputs, however, is normally better described as engineering analysis.

An engineering project commonly aims to produce a required solution. Research aims to produce additional knowledge about an uncertain question. One project can contain both.

No. Publication does not initially define whether the work is R&D, but peer review, publication and external critique are important mechanisms for evaluating and transferring research findings.

Yes. Originality can lie in the research question, methodology, analysis or context. The source, suitability and limitations of the dataset should be documented.

04Related Insights

More from this archive

Engineer holding a tablet on a CNC shop floor with five labelled machining centres — CNC1 running, CNC2 waiting, CNC3 running, CNC4 overloaded and CNC5 waiting — beside staging carts for turning, milling, drilling and inspection operations, looking at a wall-mounted production plan board showing a weekly schedule for four products, capacity-loading charts per machine, material-availability status and a list of key planning actions.
CNC and ManufacturingPublished

How Production Planning Affects Manufacturing Efficiency

A manufacturing process can be technically capable and still perform poorly. This article examines why manufacturing efficiency starts before production begins — in how production planning coordinates demand, materials, capacity, tooling, maintenance and sequence — using two original frameworks, the Production Planning–Efficiency Chain and the Plan–Execute–Learn Loop, to show why local machine utilization is not the same as system efficiency.

19 min read
Close-up of a CNC vertical machining centre spindle above a clamped workpiece, with an overlay diagram distinguishing Machine Zero, the fixed reference point of the CNC machine, from Work Zero, the programmed origin on the workpiece, showing both origins use X, Y and Z axes but at different physical locations.
CNC and ManufacturingPublished

CNC Coordinate Systems Explained

A CNC program line as simple as G0 X20 Y10 is meaningless without knowing which coordinate system X20 and Y10 belong to. This article works through the relationship between machine coordinates, work offsets, program coordinates and physical tool position — using G53, G54–G59, G90/G91 and a worked milling example — to show why correct G-code cannot compensate for an incorrect reference setup.

18 min read
Four mechanical engineering students gathered around a workbench examining a partially assembled gearbox test rig, with one student adjusting a component, another holding a dial indicator against the shaft, a laptop showing a CAD model, and engineering drawings, a multimeter and machined parts spread across the table in a university engineering laboratory.
Technology EducationPublished

Project-Based Learning in Mechanical Engineering Education

Mechanical engineering problems rarely arrive as isolated textbook questions — they require students to integrate mechanics, materials, manufacturing, design and testing at once. This article examines why Project-Based Learning suits that integration, why a project is not automatically PBL, and how meaningful decisions, scaffolding, evidence, iteration and individual assessment separate genuine engineering learning from simply producing an artifact.

20 min read
05About the Author
Harun Lucas working at his desk, reviewing code and systems dashboards across multiple monitors

Harun Lucas

Mechanical Engineer · Technology Education Researcher · Engineering Systems Developer

Harun writes from the same practice covered on this site — mechanical engineering, technology education research, and engineering systems development — connecting hands-on work with the ideas behind it.

More About Harun