Tampere University Embedded Systems Master's Thesis Guide: 30 ECTS, COMP.CE-S03 and Trepo

Quick answer: what governs the Embedded Systems thesis?

Tampere University’s Embedded Systems study option is a 120 ECTS, two-year Master of Science (Technology) specialisation in Computing Sciences and Electrical Engineering. The current programme-specific advanced-studies object is COMP.CE-S03 Advanced Studies in Embedded Systems, worth at least 80 ECTS and current through the 2026–2027 curriculum. Because the degree is Master of Science (Technology), the thesis follows Tampere’s Technology/Architecture thesis framework: the thesis itself is 30 ECTS and is graded on the 0–5 scale.

The Embedded Systems curriculum is unusually useful for thesis planning because it names the technical capabilities the programme expects: requirements specification, hardware/software co-design, board-level integrated devices, microcontrollers and programmable logic, peripherals and buses, real-time and resource-constrained software, product development and productisation, platform evolution, ethics and sustainability. Those capabilities define a credible academic domain, but they do not force every thesis to contain hardware fabrication or firmware.

A current CSEE preparation course, ITC.CEE.800 Tools for theses, is 5 ECTS and pass/fail. However, the current public COMP.CE-S03 page does not establish that course as compulsory inside every Embedded Systems study plan. Treat it as a current CSEE thesis-preparation object whose exact placement must be verified in your own Sisu plan. Tampere’s university-wide Technology thesis rules still require thesis-seminar/presentation activity; use current Sisu/Moodle instructions for the operational seminar registration.

1. Start from COMP.CE-S03, not a generic electronics thesis

Embedded Systems sits between electronics and software engineering. The current module describes programmable devices that sense or control the physical world, often under real-time, memory, power, compute or physical-size constraints. It includes both hardware and software design rather than treating one as merely an accessory to the other.

That breadth makes thesis scoping important. A topic can focus on firmware, operating systems, drivers, board-level electronics, interfaces, embedded Linux, IoT devices, hardware/software architecture, energy-aware computing, dependable systems, sensor integration or productisation. A thesis does not need to cover all these layers. Strong projects identify the layer that carries the research question and treat the rest as controlled context.

2. What the 30 ECTS Technology thesis means

The 30 ECTS value describes the academic thesis workload and degree requirement, not a fixed engineering artefact. Tampere allows empirical research, planning and implementation, and literature-review approaches within the Technology thesis framework. An Embedded Systems thesis may therefore be experimental, analytical, implementation-led, simulation-based, measurement-driven or literature-based when the design fits the question.

The distinction between an engineering deliverable and a thesis contribution matters. A working PCB, driver, firmware image or IoT prototype demonstrates implementation. The thesis must still establish a research or development problem, justify the method, produce interpretable evidence, analyse trade-offs and state limitations. “It works” is often the beginning of evaluation, not the final conclusion.

3. Turn a device idea into a researchable question

“Build an IoT sensor”, “develop embedded Linux software” or “design a low-power device” are project descriptions. Convert them into questions with a system boundary, comparison and measurable outcome. For a low-power design, specify the workload, hardware platform, power states, sampling or communication pattern, baseline and energy metric. For a driver or OS study, define the timing, reliability or resource property being evaluated.

Avoid promising an entire product lifecycle inside one thesis. Requirements, hardware design, firmware, cloud integration, cybersecurity, enclosure design, certification and manufacturing can become several independent projects. Decide which decisions the thesis will evaluate academically and which are implementation constraints.

4. Hardware/software co-design: document the partition

Embedded Systems often gains performance or energy advantages by deciding which functions belong in software, programmable logic, dedicated hardware or peripherals. That partition is part of the method. Record what runs where, what interfaces connect the parts and why the partition was chosen.

If two designs are compared, keep the functional workload equivalent. A hardware accelerator and a software baseline should process comparable inputs and produce comparable outputs. Report the costs that matter: latency, throughput, resource utilisation, power/energy, memory, logic area, development complexity or flexibility, depending on the question.

5. Firmware and real-time theses

For firmware research, specify the target processor or board revision, compiler and optimisation settings, operating system or scheduler, clocking, memory configuration and relevant peripheral state. Timing claims can change when any of these change.

Average execution time is not always enough for real-time systems. If the claim concerns deadlines or determinism, consider worst-case observations, percentile latency, jitter or deadline-miss rates. Explain how timing was measured and whether instrumentation itself affects execution.

If concurrency is involved, document task priorities, interrupt handling, synchronisation and shared-resource behaviour. Race conditions or rare timing failures can disappear in short tests, so choose test duration and workload deliberately.

For dependability claims, define the fault model explicitly. A watchdog recovery test, communication timeout, brown-out event or corrupted input exercises different failure mechanisms. Record how faults are injected, what counts as recovery, how long recovery takes and whether state or data are lost. If the thesis uses fault injection, repeat it across representative operating states rather than only the easiest nominal state.

Embedded benchmarking also needs warm-up and state control. Cache state, flash wait states, dynamic frequency scaling, radio association, filesystem buffers and power-management transitions can change repeated measurements. Decide whether the study represents cold start, steady state or a controlled transition, then keep that condition consistent across comparisons.

6. Resource-constrained systems: choose metrics that answer the question

Embedded devices may be limited by flash, RAM, processor time, battery capacity, thermal budget, radio duty cycle or physical size. Do not report every metric simply because a tool exposes it. Select metrics that connect directly to the research objective.

For an energy study, distinguish instantaneous power from energy per task or operating cycle. For memory studies, distinguish static allocation, peak runtime use and persistent storage. For compute-limited designs, state whether utilisation, execution time, throughput or deadline behaviour is the meaningful outcome.

When comparing platforms, normalise the workload. A faster processor that completes work sooner may consume more power but less energy per task; another design may trade latency for battery life. The discussion should explain the engineering trade-off rather than selecting a single headline number.

7. Hardware and board-level experimental work

COMP.CE-S03 explicitly includes board-level integrated-device competence, microcontrollers, programmable logic, peripherals, interfaces and buses. For a measurement-based hardware thesis, preserve the information needed to interpret results: board revision, component variants, firmware revision, supply conditions, clock settings, instrumentation, probe placement, calibration and environmental conditions when relevant.

Prototype boards are not perfect measurement instruments. Oscilloscope bandwidth, shunt resistance, power analyser sampling, cable losses and fixture design can change a result. State measurement uncertainty or limitations when they are material to the claim.

If a custom PCB is involved, separate design verification from research evaluation. Power rails, clocks and interfaces working correctly establish that the platform is usable. The thesis question normally requires an additional evaluation beyond bring-up.

Plan a test matrix before the final board arrives. Map each research claim to the stimulus, measured output, instrument, acceptance or comparison criterion and repetition strategy. This reduces the risk that the last available hardware revision produces data that cannot answer the question. Where destructive or irreversible testing is possible, decide the order of tests so one experiment does not invalidate the remaining evidence.

8. Embedded Linux, drivers and system software

The applicant-facing programme page explicitly lists embedded Linux drivers among current study topics. A software-focused thesis can therefore be fully aligned with Embedded Systems without designing new hardware.

For driver, kernel or system-software work, record kernel/OS version, toolchain, configuration, hardware target and dependencies. Define functional tests separately from performance or reliability tests. Successful device enumeration or data transfer proves functionality, not necessarily latency, robustness or efficiency.

If open-source components are modified, identify the version or commit used. If company source code cannot be published, provide enough architecture, interface and evaluation detail for academic scrutiny without exposing confidential implementation.

9. IoT and networked embedded systems

IoT systems combine device constraints with communication and remote services. Decide whether the thesis contribution is in the device, protocol, networking behaviour, energy management, security architecture or application. Otherwise evaluation can become diffuse.

If radio communication affects energy or latency, describe the protocol, firmware, transmission interval, payload, retry behaviour and network conditions. If cloud processing is only a support component, avoid making untested claims about end-to-end scalability.

Security-sensitive IoT theses should define the threat model. “Secure” is too broad. State the attacker capability, protected asset and security property being evaluated, and do not expose credentials or exploitable production details in the public thesis.

10. Productisation: prototype is not production readiness

The programme explicitly includes embedded-systems productisation, and current EE.ELE.510 illustrates topics such as documentation, productisation planning, prototypes, sourcing, PCB/mechanics co-design, factory testing, conformity testing and manufacturing phases. This course is useful evidence of the current academic environment, but this guide does not claim it is compulsory for every student.

A productisation-oriented thesis should distinguish technical feasibility from production readiness. A laboratory prototype may work while still lacking tolerance analysis, manufacturing testability, supply-chain robustness, conformity evidence or reliability validation. Define which stage the thesis evaluates.

If the work compares prototype revisions or manufacturing-test strategies, preserve configuration control. Record board/firmware versions and test criteria so results from different revisions are not accidentally mixed.

11. Verification versus validation

Verification asks whether the implementation behaves according to its specification. Validation asks whether the design and evidence support the real-world claim. Unit tests, simulation checks, interface tests and reference vectors can support verification. Field data, calibrated measurements or representative workloads can support validation.

State which level the thesis achieves. A model may be internally correct but insufficient for predicting real hardware. A prototype may pass functional tests but not demonstrate long-term dependability. Being precise about this boundary strengthens the discussion.

For coupled hardware/software systems, verify interfaces and assumptions between layers. A result may be dominated by communication overhead, driver buffering or scheduling rather than the algorithm intended for study.

12. ITC.CEE.800 and the seminar boundary

Current ITC.CEE.800 Tools for theses is 5 ECTS, pass/fail. Its four current components are research methods, research ethics, information searching skills and career planning, and Tampere recommends completing the course before thesis work.

However, the current public COMP.CE-S03 module does not establish ITC.CEE.800 as a compulsory Embedded Systems component. Do not infer compulsory placement solely because earlier CSEE programmes used it. Check your current Sisu study plan and programme instructions.

Similarly, Tampere’s Technology thesis rules require seminar participation, an oral presentation and opposition-related thesis activity, but the current public Embedded Systems module does not expose a separate Embedded-specific seminar course code. Follow the current programme-specific Sisu/Moodle implementation rather than resurrecting an old seminar code.

13. Topic, supervisor and research environment

Begin topic searching early. Tampere allows university, company and independently proposed topics, while the university retains responsibility for academic suitability and supervision. The applicant page specifically points Embedded Systems students toward Tampere Electronics Research Centre as an environment for finding supervisors and research topics.

Match the supervisor to the technical centre of gravity. A thesis dominated by real-time software may need different expertise from an RF-connected sensor board or an electronics productisation study. For cross-layer work, identify who can supervise the primary academic question and who can advise secondary engineering layers.

14. Thesis Supervision Plan and project controls

The Technology thesis process uses a Thesis Supervision Plan. Agree on scope, research question, method, deliverables, meeting rhythm, feedback, schedule and examiner arrangements early.

For embedded projects, add resource dependencies: development boards, components, PCB fabrication, laboratory access, measurement equipment, licensed tools, company hardware, private repositories and test environments. Supply-chain delays can invalidate a schedule, so identify alternatives before ordering or fabrication becomes critical.

Version control is especially important. Freeze identifiers for board revision, firmware, HDL, software dependencies, test scripts and datasets. A thesis result that cannot be tied to the exact tested configuration becomes difficult to defend.

15. Research plan: separate build work from evidence generation

Write the research question and evaluation plan before the implementation becomes large. Define the baseline, variables, metrics, repetitions and analysis strategy. Then build what is required to generate that evidence.

For prototype theses, divide the plan into platform bring-up, verification and research evaluation. This prevents weeks of necessary engineering work from being mistaken for academic analysis. If the platform fails to become available, discuss a fallback,simulation, existing hardware or reduced scope,with the supervisor before changing the research question.

16. Data, ethics and confidential systems

Embedded devices can collect sensor data, identifiers, telemetry, location or health-related information. If personal data is involved, agree on processing with the supervisor and follow Tampere data-protection guidance. Collect only what the research requires and document preprocessing and access controls.

Industry projects often contain proprietary hardware, schematics, source code or test data. Tampere theses are public documents. Plan from the start what can appear in the public manuscript and what confidential material must remain outside it. The public thesis still needs enough method and evidence to support academic assessment.

17. AI use in Embedded Systems work

Tampere permits AI use within its current study guidance, but the student remains responsible for the work. AI-assisted code, HDL, debugging suggestions, literature summaries or language editing must be treated as assistance, not verified engineering truth.

Test generated code and check hardware assumptions against datasheets and actual measurements. Do not trust invented register names, protocol requirements or citations. Follow acknowledgement requirements when AI materially contributes.

Never paste company code, credentials, unpublished hardware details, personal data or restricted datasets into an AI service unless the applicable rules permit it.

18. Writing the thesis while engineering continues

Start writing before the prototype is finished. Maintain a design-decision log, version table, experiment plan and results index. Record failed approaches when they affect the final method or reveal limitations.

Separate requirements, implementation and evaluation chapters conceptually. Readers should be able to tell what the system was supposed to do, what was actually built, how it was tested and what the evidence supports.

Use figures strategically: architecture diagrams, timing diagrams, state machines, measurement setups and experiment flows can communicate embedded-system behaviour more clearly than long prose, but every figure should support the argument.

19. Maturity test, Turnitin and final submission

The master’s degree requires the maturity test under Tampere’s current rules. For international master’s students, the thesis abstract normally serves as the maturity test at MSc stage under the current Technology guidance, while individual language-history situations can affect the route.

After supervisor permission, the final thesis goes through Turnitin originality checking. Similarity is not an automatic plagiarism verdict; it requires academic interpretation. Resolve citations, reused text and source attribution before final submission.

The final thesis is then deposited through Tampere’s process in Trepo. Protect time for administrative completion as well as technical work.

20. PDF/A, publicity and company confidentiality

Permanent electronic archiving requires a valid PDF/A file. Test conversion early enough to catch font, equation, figure or embedded-object problems.

The approved thesis is public. A company cannot make the evaluated thesis confidential simply because the project is commercially sensitive. Keep confidential details outside the public thesis and write the public document so that the academic reasoning and evidence remain assessable.

21. Assessment, examiner response and finality

Embedded Systems uses the Technology thesis 0–5 grading scale, not Architecture’s pass/fail exception. ITC.CEE.800, if included in your own plan, is a separate pass/fail course and does not determine the thesis grade.

Tampere uses formal examiners and the university assessment criteria. The examiners normally have 21 days after the Trepo/submission process, extended to 28 days where the applicable maturity-test route requires it. Students can respond to the proposed assessment under the current process, and an approved thesis is final rather than freely resubmittable.

22. Graduation planning

A technically finished device is not the same as an approved degree. Work backwards from the desired graduation date through supervisor review, final tests, writing, Turnitin, PDF/A, Trepo, examiner time and the separate graduation application.

Leave margin for hardware failures and component delays. The final weeks should not depend on receiving a new PCB revision or fixing a fundamental firmware architecture issue.

23. Final Embedded Systems checklist

Before starting, verify the current COMP.CE-S03 placement in your Sisu plan, the 30 ECTS Technology thesis, supervisor, topic and any current seminar/course registration. Check whether ITC.CEE.800 belongs to your own plan rather than assuming it. Freeze your research question, tested configuration, metrics and evidence plan before implementation expands.

Before submission, confirm that every technical claim is supported by the tested hardware/software version, discuss uncertainty and limitations, remove confidential material, complete the maturity requirement, follow Turnitin, create valid PDF/A, submit through Trepo and complete the separate graduation steps.

The safest principle is to keep three layers separate: Tampere’s institutional rules, COMP.CE-S03 programme competence, and your research design. A strong Embedded Systems thesis does not need to build everything. It needs a bounded technical question, controlled configuration, credible evidence and conclusions that stay within what the tested system actually demonstrates.