University of Turku Smart Systems Master’s Thesis Guide: KTEK0015, 30 ECTS, Control, Robotics, ML and UTUGradu

What this guide covers

This guide is for the University of Turku Smart Systems specialisation track in the current 2024-2027 Mechanical Engineering curriculum. It is tied to the exact Peppi object KTEKDIALYJAR2427, programme 99959, rather than to a generic robotics, automation or AI programme. The key structural rule is that the 40 ECTS Thesis and Project category contains four separate objects: KTEK0015 Master’s Thesis in Technology, Mechanical Engineering, 30 ECTS; KTEK0026 Master’s Thesis in Technology Seminar, Mechanical Engineering, 5 ECTS; TTDK1308 Degree Qualifying Examination, 0 ECTS; and KTEK0016 Project Work, Mechanical Engineering, 5 ECTS. The guide then explains how systems engineering, control, modelling, digital twins, mechatronics, robotics, machine learning, perception, autonomy and hands-on integration should be converted into defensible thesis evidence.

Current programme object

The current Peppi programme object is KTEKDIALYJAR2427, programme 99959, for the 2024-2027 curriculum. The degree is Master of Science (Technology), organised in the Faculty of Technology and connected to the Department of Mechanical and Materials Engineering. The formal degree size is 120 ECTS and Smart Systems is one of the three Mechanical Engineering specialisation tracks. Use the curriculum period attached to your own study right and HOPS when planning the thesis. Do not copy a thesis package from Materials Engineering or from an older Smart Systems curriculum without checking the current Peppi structure first.

How the 120 ECTS degree is structured

The public programme structure combines 20 ECTS Joint studies in Mechanical Engineering, 20 ECTS Smart Systems studies, a 40 ECTS Thesis and Project category, 20-25 ECTS Minor or Thematic Studies and 15-20 ECTS Other Studies. Peppi models the Advanced Studies module as 80 ECTS. The root can display 115-125 ECTS because of selectable module ranges, but that range does not replace the formal 120 ECTS degree size. Smart Systems includes KTEK0036 Smart Systems Engineering as a mandatory 5 ECTS course, with the remaining track credits selected from current approved options in intelligent control, modelling, mechatronics, robotics, machine learning, autonomous systems and hands-on smart-system work.

Read the 40 ECTS Thesis and Project category correctly

The 40 ECTS category is not a 40 ECTS thesis. KTEK0015 is the individually examined 30 ECTS master’s thesis. KTEK0026 is a separate 5 ECTS thesis seminar. TTDK1308 is the 0 ECTS maturity examination. KTEK0016 is a separate 5 ECTS Project Work course. All four appear inside the same category, but their academic purposes and assessment are different. The seminar and project must not be added to the thesis credit. This Mechanical Engineering package also differs from the Materials Engineering tracks, so the structure must be verified programme by programme rather than inherited.

Exact thesis course: KTEK0015

The exact current thesis course is KTEK0015 Master’s Thesis in Technology, Mechanical Engineering, 30 ECTS. The course expects scientific work, management of research methods, knowledge of the research field and scientific writing. A Smart Systems thesis may involve a physical system, controller, simulation, digital twin, machine-learning model, robotic platform, sensing architecture or a combination of these. The technical artefact is not the thesis contribution by itself. The thesis still needs a research problem, justified method, traceable evidence and conclusions that stay within what the evidence actually supports.

The separate KTEK0026 thesis seminar

KTEK0026 Master’s Thesis in Technology Seminar, Mechanical Engineering is a separate 5 ECTS course inside the 40 ECTS category. It supports thesis planning, discussion of research approaches and presentation of the research plan and near-final results. It does not change KTEK0015 from 30 ECTS to 35 ECTS. Use the seminar to test whether the research question, method, validation strategy and evidence boundaries are understandable to others. The seminar can improve the thesis, but it remains its own academic object and should be reported separately in the degree structure.

The separate KTEK0016 Project Work course

KTEK0016 Project Work, Mechanical Engineering is a separate 5 ECTS course in the same 40 ECTS category. Project work can provide an industrial problem, prototype platform, sensor setup, robot, data pipeline or integration environment that later supports a thesis. However, successful project delivery does not replace individual KTEK0015 examination. If the project and thesis use the same platform, define what was already completed for the project course and what new, individually defensible research is performed for the thesis. This prevents double counting and makes the thesis contribution easier to evaluate.

TTDK1308 maturity examination

TTDK1308 is the 0 ECTS Degree Qualifying Examination for the master’s degree. In the normal route, the thesis abstract or another suitable part of the thesis can function as the maturity test and demonstrate knowledge of the field. A conditional written route can apply depending on previous degree and Finnish or Swedish educational-language background. The route is student-specific, so do not copy another student’s procedure. Recheck your HOPS and current University instructions before final submission so that a maturity requirement does not become the last unresolved degree item.

Finding a Smart Systems thesis topic

The official programme page gives examples such as intelligent control of mechatronic systems, digital twins, autonomous robotic decision-making, predictive condition monitoring, reinforcement learning for production scheduling and AI-based energy-efficient automation. These are examples, not mandatory topics. A good thesis topic should be narrow enough for 30 ECTS and should connect one research question to one defined evidence chain. Instead of asking whether a system is “smart”, define whether you are evaluating tracking performance, prediction accuracy, fault detection, navigation success, energy consumption, model fidelity, requirement satisfaction, robustness or another measurable outcome.

Build the thesis plan around an evidence chain

Before implementing code or hardware, write down the problem, research questions, stakeholder needs, engineering requirements, system boundary, model assumptions, datasets, sensors, actuators, controller or ML method, test environment, validation strategy, risks, confidentiality and expected outputs. Smart Systems projects can expand rapidly because modelling, control, sensing, software, communication and hardware each introduce dependencies. A written plan prevents the work from becoming a demonstration without a research argument. It also exposes long-lead risks such as equipment access, company approvals, data collection, robot availability, simulation time or integration failures.

Use supervision as evidence control

Regular supervision should be used to review methodological decisions, not only progress. Discuss requirement changes, model assumptions, controller tuning, sensor calibration, data exclusions, train-test splitting, robot configuration, environment changes, failed experiments and safety constraints. Record important decisions so the Methods and Discussion chapters can explain why the approach changed. When a thesis moves from model to controller, from controller to simulation and then to hardware, ask at each step what new evidence has been added and what claims remain unsupported.

How examination and grading work

The current KTEK0015 evidence states that at least two examiners evaluate the thesis under University evaluation and grading guidance. Final acceptance is decided by the head of the department, and the grade is based on examiner evaluation. Supervisor involvement therefore does not replace formal examination. Write so an examiner can trace the research question through requirements, literature, method, data, model or controller design, experiment, validation, uncertainty and conclusion. A sophisticated robot or impressive demo cannot compensate for an unclear research question or an unvalidated technical claim.

Start from systems engineering requirements

KTEK0036 Smart Systems Engineering makes requirements, architecture, integration, verification and validation central to the track. Distinguish stakeholder needs from formal engineering requirements. A useful requirement should be measurable or otherwise testable when it will later be verified. Preserve traceability from need to requirement, from requirement to design decision and from design decision to evidence. If requirements change after implementation, record the change and explain how it affects the basis of evaluation. A system architecture diagram is useful, but the diagram itself does not prove that the implemented system satisfies the requirements.

Keep verification and validation separate

Verification asks whether the specified system or subsystem requirements were met. Validation asks whether the resulting system addresses the intended use or problem. These are related but not interchangeable. A controller may meet a simulated tracking requirement while the physical system still fails under sensor noise or actuator saturation. A perception module may meet an offline accuracy target while navigation fails in a real environment. Plan separate evidence for the requirements that matter. A strong thesis states which requirements were verified, which aspects were validated and which remain outside the available evidence.

Treat interfaces and integration as evidence

Smart systems combine mechanical, electrical, sensing, actuation, control, communication and software elements. Interface assumptions can become failure sources even when individual components perform well. Document communication protocols, timing, coordinate frames, power assumptions, data formats and hardware-software dependencies where they affect the result. A component passing its own test does not prove the integrated system works correctly. System-level integration testing should check the interactions that the thesis conclusion depends on, and failures or workarounds should be reported rather than removed from the narrative.

Safety, security and physical constraints belong in the system boundary

The Smart Systems Engineering course explicitly includes smart-system safety and security, EMC and electrical noise, power, thermal and moisture management, system stability and control. These are not automatically central to every thesis, but they should not be ignored when they constrain the intended use. A robot that completes a task is not therefore safe. A wireless controller that works in a lab is not therefore secure or robust in every environment. If the thesis makes safety, reliability or secure-operation claims, define the relevant requirement and collect evidence appropriate to that claim.

Intelligent Control: define the plant, assumptions and metrics

KTEK0038 Intelligent Control covers nonlinear control, Lyapunov stability, feedback linearisation, adaptive schemes, fuzzy systems, neural networks and intelligent controllers. A control thesis should define the plant or model used for design, the operating regime, initial conditions, disturbances, constraints and performance metrics. Tracking error, overshoot, settling time, energy use and robustness measure different properties. Choose metrics before comparing controllers and use equivalent conditions. A mathematically elegant control law is not automatically a practically superior controller unless the evaluation addresses the intended engineering requirement.

Stability is not the same as real-world robustness

A stability result established under stated mathematical assumptions should be reported at that level. It does not automatically prove acceptable behaviour with actuator saturation, measurement noise, communication latency, parameter drift or unmodelled dynamics. Likewise, a stable simulation does not prove safe physical operation. If robustness is part of the research question, introduce the uncertainty or disturbance that defines robustness and test it explicitly. Hardware-in-the-loop or physical experiments can strengthen the claim, but they remain bounded to the tested equipment and conditions.

Compare intelligent controllers against a meaningful baseline

If a fuzzy, neural, adaptive or learning controller is claimed to improve performance, define a baseline and compare under equivalent operating conditions. A more complex controller may reduce one error while increasing energy use, sensitivity or computation. Report trade-offs rather than selecting only the favourable metric. If the intelligent component learns from data, separate model-training effects from controller-level behaviour. Repeated trials are useful when stochastic training, sensor noise or changing environments can affect the result.

Smart Systems Modelling: identify what the model represents

KTEK0039 Smart Systems Modelling covers static and dynamic, continuous and discrete, linear and nonlinear, lumped and distributed models, plus physics-based, data-driven and hybrid modelling. State the variables, parameters, states and physical relationships that the model includes and what it omits. Model fidelity should be appropriate to the research question, not maximised without purpose. A result with many decimal places is not therefore physically accurate. The thesis should explain why the chosen model is sufficient for the claim being made.

Separate calibration from independent validation

If parameters are fitted using measured data, that dataset contributes to calibration. It should not then be described as fully independent validation without acknowledging the dependency. Use separate data, operating points or benchmark cases where appropriate. A model can fit calibration data very well and still generalise poorly. If only calibration evidence is available, say so. Sensitivity analysis can show whether uncertain parameters materially change the predicted outcome and can identify where stronger measurements would improve confidence.

A digital model is not automatically a digital twin

Digital Factory and Smart Systems Modelling both introduce digital models and digital twins. A CAD model, simulation or dashboard should not automatically be called a digital twin. Define the physical system, digital representation, data exchange or update mechanism and the purpose of the relationship. A digital twin with live data is not automatically predictively accurate. If the thesis claims prediction, state how predictions are compared with reference physical data. If real-time behaviour is claimed, latency and update rate may be part of the evidence.

Hybrid modelling needs a clear division of labour

A hybrid model combines physics-based and data-driven elements. Explain what each part is responsible for, how information moves between them and why the combination is justified. Do not allow a data-driven correction to hide an incorrect physical assumption without discussion. If the ML part is trained on outputs from the same physics model, the evidence is not independent physical validation. Keep the provenance of simulated and measured data visible so the reader can understand what the hybrid result actually demonstrates.

Mechatronics: choose sensors and actuators from requirements

KTEK0053 Mechatronics covers sensors, actuators, measurement systems, real-time control, data communication and condition monitoring. Sensor selection should match the physical variable, range, bandwidth, environment and uncertainty needed for the research question. Actuator selection should match force, torque, speed and dynamic requirements. Nominal sensor resolution is not the same as measurement accuracy or uncertainty. Report calibration, signal conditioning and acquisition settings when they materially affect the conclusion.

Condition monitoring: detection, diagnosis and prognosis differ

A condition-monitoring thesis should say whether the goal is to detect an abnormal condition, diagnose a fault type or predict remaining life. These are different evidence levels. An unusual vibration signal can support anomaly detection without proving the root cause. A classifier can label known fault classes without proving future failure time. Choose ground truth and evaluation metrics that match the stated task. If the data come from laboratory faults rather than real field degradation, keep that limitation visible in the conclusion.

Robotics: define the robot, task and environment

KTEK0054 Robotics covers robot design, components, autonomous robotics, collaborative robotics, AI, legal issues and standardisation. A robotics thesis should define the platform, sensors, actuators, task and environment before claiming performance. A robot that succeeds in one demonstration is not automatically robust to new environments, payloads or disturbances. If the research concerns autonomous behaviour, explain which decisions are made without human intervention and which are scripted, remotely controlled or constrained by the test setup.

ROS implementation is not the research result by itself

DTEK2081 Algorithmic Foundations of Robotic and AI Systems uses the Robot Operating System and covers motion planning, optimisation, control, localisation, mapping and learning systems. Implementing an algorithm in ROS is an engineering step, not automatically a research contribution. The thesis should define what property is evaluated, such as planning time, path quality, localisation error or task success. Software architecture, package versions and configuration should be traceable when they affect reproducibility.

Perception and navigation are different evidence levels

DTEK2083 Perception and Navigation in Mobile Robotics covers images, point clouds, radar, inertial data, mapping, navigation and planning. A perception model may achieve high offline accuracy while the robot still navigates poorly. Navigation can fail because of localisation, planning, control, latency or environment changes even when perception is strong. Evaluate the layer that matches the thesis claim. Simulation-based navigation evidence should be labelled as simulation unless physical-robot testing is also performed.

Multi-robot and aerial systems require communication assumptions

DTEK2084 Aerial Robotics and Multi-robot Systems addresses real-time communication, coordination, autonomous navigation and perception. Multi-robot results can depend on network reliability, timing, shared maps, synchronisation and assumptions about other agents. State those assumptions. A coordinated simulation does not automatically prove equivalent physical multi-robot behaviour. Aerial-robot performance should be bounded to the tested platform, sensors, flight environment and safety controls.

Autonomous-system architecture is not physical validation

DTEK8085 Autonomous Systems Architectures covers intelligent agents, multi-agent systems, communication, ontologies, decision-making, teamwork, competition and negotiation. Agent architecture can support a rigorous software or algorithmic thesis, but simulated agent behaviour is not automatically physical robotic behaviour. Distinguish formal or simulated decision-making from sensing, actuation and hardware constraints. A multi-agent system can satisfy a coordination objective without proving that the complete physical system is safe or robust.

Machine learning: define the target and unit of generalisation

KTEK0055 Machine Learning for Mechanical Engineering and TKO_3120 Machine Learning and Pattern Recognition provide track-relevant ML methods. Before choosing a model, define the prediction target, input features, data unit and intended decision. Decide whether the model must generalise to a new time period, machine, robot, component, environment or operating condition. That decision should control the data split and evaluation design. A random split is not automatically valid when observations from the same physical run or device are strongly related.

Prevent leakage in sensor and time-series data

Smart-system datasets often contain many rows from one run, machine, robot or subject. If related rows are placed in both training and test sets, performance can be inflated. Grouped or temporal splitting may be necessary when the research claim is about generalisation to new runs or future time periods. Feature engineering and preprocessing should be fitted without leaking information from the evaluation set. The thesis should describe the split at the physical data-unit level, not only as percentages of rows.

Choose ML metrics that match the engineering decision

Classification accuracy can hide poor performance on rare but important faults. Regression metrics can emphasise different error behaviours. Choose metrics that reflect the engineering decision and, where relevant, report class-wise performance, confusion matrices or error distributions. Compare with a simple baseline so the benefit of added complexity is visible. Model selection should not be repeatedly tuned against the final test set, because that weakens the independence of the reported performance estimate.

Predictive performance does not prove a physical mechanism

A high ML score shows predictive behaviour under an evaluation design. It does not automatically establish the physical mechanism behind the prediction. Feature importance is also not automatically causal evidence. If the thesis aims to explain a physical process, combine the predictive result with theory, controlled experiments or other evidence appropriate to mechanism. If the thesis is primarily predictive, keep the conclusion at that level and avoid turning correlations into unsupported causal statements.

Reinforcement learning needs its own evaluation boundary

If reinforcement learning is used, define the environment, state, actions, reward and evaluation protocol. Success in simulation does not automatically transfer to a physical system because dynamics, sensing and safety constraints can differ. If transfer is part of the thesis, test or otherwise evaluate the gap explicitly. A reward function also defines what the agent is encouraged to optimise, so a high reward should not be treated as proof that every engineering objective has been satisfied.

Offline ML performance is not real-time autonomy

A model evaluated on stored data has not yet demonstrated real-time system performance. Runtime behaviour can be affected by sensor latency, missing values, compute limits, communication and distribution shift. If the thesis claims online detection, control or autonomy, report the runtime pipeline and timing constraints relevant to the decision loop. A model that is accurate but too slow for the required control interval may not satisfy the system requirement.

Hands-on Smart Systems: separate prototype integration from thesis evidence

KTEK0065 Hands-on Smart Systems focuses on proposing, applying and testing methods to build a real smart system. It is valuable preparation for system integration, but a functioning course project is not automatically a thesis contribution. If the same platform is used later, identify which hardware, software and integration work already existed and what new research question the thesis addresses. Test the final system against thesis requirements rather than judging success only by whether the prototype operates.

Digital Factory and system data need precise claims

KTEK0011 Digital Factory covers digital models, digital twins, manufacturing data, IoT, cloud-based data, PLM and manufacturing execution systems. A data pipeline or dashboard may improve observability or traceability, but it does not automatically prove intelligent decision-making or improved product quality. Define the claim and corresponding metric. If a digital-factory component feeds a controller or ML model, show how data quality, timing and missing-data behaviour affect the downstream result.

Axiomatic Design can support requirement traceability

KTEK0013 Axiomatic Design can help structure functional requirements and design parameters. If used, show how stakeholder or system needs are decomposed and connected to design decisions. A simpler architecture is not automatically superior unless the chosen requirements and evaluation criteria support that conclusion. The value of a design method comes from transparent reasoning and traceability, not from naming the method after the final design has already been selected.

Company work and NDA boundaries

KTEK0015 may be connected to company or research-group problems, and KTEK0025 Industrial Internship can provide practical experience. Before using confidential sensor logs, control parameters, system architecture, cost information or performance data, agree what can appear in the public thesis and what examiners need to access. A company-requested smart-system solution still requires an academic research question and defensible method. Confidentiality should not make the scientific basis impossible to examine.

Keep code, data and configurations reproducible

Preserve the artefacts needed to reconstruct the reasoning: raw sensor data, calibration records, model versions, controller parameters, ML preprocessing, train-test partitions, random seeds, robot maps, ROS package versions, simulation configuration, firmware, hardware revision and final figure provenance. Record important failed trials and design changes when they affect interpretation. Reproducibility does not require public release of confidential company assets, but the research group and examiners should be able to understand how each important result was produced.

AI use must remain accountable

University guidance on responsible AI does not transfer responsibility away from the student. If AI assists with code, literature triage, translation, data cleaning or drafting, verify the output and follow current University, faculty and supervisor instructions. Do not allow a generative system to invent references, sensor values, controller parameters, robot experiments or model results. Distinguish AI used as part of the research method from AI used as a productivity aid. If an AI model influences engineering decisions, document its role and validation at the appropriate scientific level.

Privacy, permits and human-participant data

A Smart Systems thesis can include cameras, wearable sensors, user studies or operational logs that contain personal data. Apply current University privacy and research-data requirements when personal data are involved. Not every master’s thesis automatically requires a centrally granted University research permit; the need depends on context, data and organisational setting. If human participants or identifiable data are involved, resolve the relevant ethical, privacy and permission questions before data collection rather than at the end of the thesis.

Make figures and tables auditable

Every technical figure should indicate whether it shows measured data, simulation, model prediction, controller output or derived analysis. Include units, operating conditions, sample or run identifiers and uncertainty where relevant. A control plot should state the reference, disturbance and operating regime. An ML result should identify the evaluation set and metric. A robot trajectory should explain the environment and localisation reference. Readers should be able to trace an important figure back to the underlying dataset, model or experiment.

A defensible chapter structure

The current public evidence does not impose one universal chapter template for every Smart Systems thesis. Use a structure that makes the research logic easy to audit. A practical pattern is Introduction, Background or Literature Review, Research Questions and Requirements, Methods, Results, Discussion, Conclusions, References and appendices where needed. Systems-heavy projects may add Architecture and Verification sections. Modelling work may separate model development and validation. Keep Results focused on what was observed or calculated and Discussion focused on interpretation, uncertainty, limitations and implications.

Turnitin checks originality, not engineering validity

University of Turku degree theses use Turnitin as part of originality checking. Similarity review is important for source use and academic integrity, but a low similarity percentage does not validate system requirements, controller stability, digital-twin fidelity, robot safety or ML generalisation. Engineering validity comes from appropriate methods, transparent assumptions, controls, validation and examiner review. Treat Turnitin as an integrity control rather than proof that the technical result is correct.

UTUGradu submission, examination and publication

UTUGradu manages the electronic higher-degree thesis process, including originality checking, examination, approval, publication and archiving. Operational instructions can change independently of the stable KTEK0015 30 ECTS rule, so recheck current instructions when submitting. Confirm that the intended final manuscript is uploaded, metadata are correct, confidentiality issues are resolved and the maturity route applicable to your background has been addressed. Do not rely on an older cohort’s screenshots when the current University process is available.

A practical Smart Systems thesis timeline

A workable sequence is: verify the current HOPS and 40 ECTS package; identify topic and supervisors; define stakeholder needs, research question and testable requirements; resolve data, equipment and confidentiality access; create the thesis plan; build or select the model and baseline; run early sensor, controller or ML pilots; establish the validation design; perform the main analysis; integrate hardware if relevant; repeat tests where variability matters; document uncertainty and failure cases; draft Methods and Results early; complete seminar and project obligations; revise the thesis; then complete Turnitin, UTUGradu, maturity and examination steps. Build contingency time for integration and equipment failures.

Final pre-submission checklist

Before submission, confirm that KTEK0015 is correctly described as the 30 ECTS thesis and the 40 ECTS category is not called a 40 ECTS thesis; KTEK0026, KTEK0016 and TTDK1308 remain separate; requirements and evidence levels are explicit; verification and validation are distinguished; model calibration and independent validation are not conflated; controller stability is not overclaimed as physical robustness; sensor and measurement limitations are documented; ML splits prevent leakage; simulation and physical evidence are labelled separately; autonomy and safety claims match actual tests; code and data provenance are traceable; NDA, privacy and permit issues are resolved; AI-assisted material is verified; and current Turnitin and UTUGradu instructions are followed.