CourseFall 2026

Friday · 12:00–16:00 · Odense U174

Demonstrations and the Individual Portfolio

Lecture 12: This chapter explains how to turn an Embedded Linux project into a defensible engineering demonstration and an attributable individual portfolio. It covers demonstration design, controlled failures, demonstration-day readiness, architecture diagrams, individual evidence, engineering decisions, experimental results, honest failure reporting, technical questioning, professional presentation of code, security and responsible disclosure, reproducibility, the final project archive, engineering handover, and common weaknesses in project presentations.

Learning objectives

✓By completing this module, the student should be able to:

✓1. plan and deliver a reliable end-to-end demonstration of an embedded Linux system;

✓2. distinguish objective evidence from requirements and unsupported claims;

✓3. design and demonstrate controlled failures and recovery;

✓4. explain architectural decisions, alternatives, limitations, and failure behaviour;

✓5. answer technical questions using evidence rather than unsupported claims;

✓6. prepare a reproducible project archive with sufficient engineering evidence;

✓7. present experimental results with appropriate measurements, uncertainty, and interpretation;

✓8. communicate technical work professionally to examiners, employers, clients, and engineering colleagues.

Block 112:00–12:50content

Block 1 · 12:00–12:50 · Demonstration Design and Controlled Delivery

CHAPTER 12

Demonstrations and the Individual
Portfolio

Learning objectives

After completing this module, the student should be able to:

plan and deliver a reliable end-to-end demonstration of an embedded Linux system;
connect project evidence to requirements and course learning outcomes;
distinguish shared team results from individually attributable competence;
explain architectural decisions, alternatives, limitations, and failure behaviour;
answer technical questions using evidence rather than unsupported claims;
prepare a reproducible project archive without exposing credentials or personal data; and
communicate technical work professionally to examiners, employers, clients, and engineering colleagues.

12.1 From a Working Prototype to Defensible Engineering

Building a prototype and demonstrating engineering competence are related but different activities.

A device may appear to work during a short presentation even though it has undocumented dependencies, unsafe default states, unreliable recovery, or code that only one team member understands. Conversely, a prototype may contain valuable engineering work even if one subsystem remains incomplete.

The purpose of the final demonstration and portfolio is therefore not to create a theatrical impression of perfection. The purpose is to make technically defensible claims and support them with evidence.

A defensible claim has four elements:

Claim: a precise statement about the system or the student’s competence.
Condition: the environment and assumptions under which the claim applies.
Evidence: a test, measurement, code extract, log, diagram, or other attributable record.
Limitation: what the evidence does not establish.

For example, the statement “our system is reliable” is too broad. A more defensible statement is:

During a controlled eight-hour network outage, the acquisition service continued recording locally at one sample every five seconds. All 5,760 expected records were stored, and the completed data file was uploaded after connectivity returned. This test demonstrates temporary network-outage tolerance, but it does not establish behaviour during storage failure or abrupt power loss.

EMBEDDED LINUX Fall 2026

The improved statement identifies the condition, metric, observed result, and boundary of the conclusion.

Demonstration as an engineering argument

A good demonstration does not merely show that something happened. It connects an observed behaviour to a requirement and explains why the evidence is sufficient, what assumptions were made, and what remains uncertain.

12.2 The Role of the Team Project

The project is normally developed by a team of approximately three students. Teamwork is appropriate because realistic embedded systems cross several technical domains:

Linux configuration and service management;
sensors, actuators, GPIO, serial buses, and electrical interfaces;
networking and distributed communication;
MQTT, LoRa, LoRaWAN, ROS 2, HTTP, or other middleware;
storage, visualization, and user interaction;
deployment, security, testing, and documentation.

The team should operate as a small engineering group. Responsibilities may be divided, but the architecture must remain coherent. A sensor subsystem developed by one student, for example, cannot be integrated responsibly unless the other team members understand its interface, units, timing, errors, and failure behaviour.

The project creates the environment in which competence is exercised. It is not, by itself, proof that every team member possesses the same competence. One excellent programmer cannot carry the technical understanding of an entire group into three individual assessments.

12.2.1 Shared ownership and individual ownership

Every major result should have both a team context and attributable individual evidence. Table 12.1 illustrates the distinction.

Table 12.1. Examples of team and individual project evidence.

Project element	Shared team evidence	Possible individual evidence
System architecture	Agreed block diagram, interfaces, requirements, and integration plan	A student’s comparison of alternatives and justification for an owned subsystem
Sensor acquisition	Integrated measurements available to the complete system	Driver code, calibration experiment, sampling analysis, fault test, and commits attributable to one student
Communication	End-to-end data exchange between nodes	Topic design, protocol framing, QoS selection, payload validation, latency test, or reconnect implementation
Deployment	System starts and operates on the target hardware	systemd unit, container definition, installation script, permissions model, rollback procedure, and deployment test

EMBEDDED LINUX Fall 2026

Project element	Shared team evidence	Possible individual evidence
Security	Agreed trust boundaries and security controls	Threat analysis, MQTT access-control policy, credential handling, negative authentication test, or input-validation code
Verification	Team verification matrix and final test session	Tests designed, executed, interpreted, and documented by the individual
Documentation	Final report and common project archive	Named sections, technical diagrams, individual reflection, reviewed pull requests, and oral explanation

Individual responsibility does not mean working alone. A student may design a component while another student reviews it. The important point is that the contribution, reasoning, and evidence can be identified.

12.3 Designing the Demonstration

A demonstration should be designed with the same discipline as a test. Randomly clicking through dashboards and terminal windows creates uncertainty and wastes time. The audience should know what the system is expected to do, which requirement is being demonstrated, and how success or failure will be recognized.

A useful sequence is:

introduce the client, problem, and operating environment;
present the main requirements and acceptance criteria;
show a block diagram of the complete system;
identify the physical inputs, processing, communication, and outputs;
demonstrate the minimum end-to-end function;
show one important measurement or quality result;
introduce a controlled fault when safe and practical;
demonstrate detection, degraded operation, or recovery;
summarize limitations and unfinished work; and
identify where the supporting evidence is stored.

12.3.1 The minimum end-to-end path

The first live demonstration should show the shortest path through the complete system. For an environmental monitoring system, this might be:

physical quantity → sensor → embedded node → communication
→ Linux service → storage → user-visible result.

For a robotic system, the path might be:

operator goal → planning or control → command interface
→ actuator → physical motion → feedback.

The audience should see the complete path before optional features. A team that begins with secondary dashboards or configuration menus may never establish that the central function works.

EMBEDDED LINUX Fall 2026

12.3.2 A demonstration script

Table 12.2 gives an example for a 12-minute project demonstration. The actual duration must be adapted to the examination arrangements communicated by the course staff.

Table 12.2. Example timed demonstration script.

Time	Stage	Action and explanation	Evidence
0:00–1:00	Problem	Identify the user, physical need, environment, and primary requirement	One problem statement and system photograph
1:00–2:00	Architecture	Explain the block diagram, trust boundaries, and principal interfaces	Numbered architecture diagram
2:00–5:00	Core function	Start the system and show the complete input-to-output path	Live values, timestamps, logs, or physical response
5:00–7:00	Measurement	Present one quantified result and compare it with its acceptance criterion	Graph, table, raw data, and calculation
7:00–9:00	Controlled fault	Disconnect a non-safety-critical dependency or inject invalid data	Health state, log event, safe response, and recovery
9:00–10:30	Engineering decision	Compare two realistic design alternatives and justify the selected one	Decision matrix or measured comparison
10:30–12:00	Limitations	State what worked, what failed, and the highest-priority improvement	Known-issues register and next-step plan

The script should assign one person to operate the hardware, one to control the presentation, and one to monitor logs or safety. For an individual presentation, the student should still know exactly where each item is located and avoid searching through folders during the examination.

12.4 Demonstrating a Controlled Failure

A system that works only when every dependency is healthy is not necessarily a reliable embedded system. A controlled failure can reveal whether the team has considered detection, safe state, degraded operation, and recovery.

Possible demonstrations include:

disconnecting a sensor and showing stale-data detection;
providing an out-of-range or malformed measurement;
temporarily blocking access to an MQTT broker;
disconnecting a network interface while local acquisition continues;
terminating an application and showing supervised restart;
restarting services in an unexpected order;
presenting invalid configuration and showing startup rejection;
sending a duplicate sequence number and showing idempotent handling; or
causing a command timeout and showing an actuator entering a safe state.

EMBEDDED LINUX Fall 2026

The team must not create an unsafe condition merely to make the demonstration interesting. Do not demonstrate uncontrolled motor movement, unsafe voltage, intentional battery abuse, damage to storage, unauthorized network access, radio interference, or bypassing a physical safety system.

Engineering caution

A fault-injection demonstration must have a bounded consequence, a defined recovery procedure, and an immediately accessible safe stop. Safety-critical behaviour should be verified before the public demonstration, not improvised in front of an audience.

A good fault demonstration answers five questions:

What exactly was changed?
How did the system detect the fault?
What state did the system enter?
What evidence shows that recovery occurred?
What would happen if recovery were impossible?

12.5 Preparing for Demonstration Day

Live demonstrations fail for ordinary reasons: a battery is empty, a cable is missing, a device receives a different IP address, credentials expire, a serial port changes name, a cloud service is unavailable, or an automatic update changes a dependency.

The team should rehearse using the actual target hardware, power supply, network, user accounts, software release, and presentation computer. A successful test on a developer’s laptop is not equivalent to a successful demonstration on the deployed target.

12.5.1 Technical readiness checklist

Table 12.3. Demonstration readiness checklist.

No.	Check	Evidence or status
1	Release tag and source revision are recorded	Tag and commit hash
2	The target boots without a development laptop	Cold-boot test
3	Required services start automatically	systemctl evidence
4	Sensor and actuator connections are labeled	Wiring diagram and inspection
5	Batteries are charged and a compatible supply is available	Voltage and runtime check
6	Network-independent functionality has been tested	Offline test record
7	Credentials are valid but not visible in slides, code, or logs	Secret review
8	The demonstration account has only required permissions	Account and ACL check
9	A safe stop procedure is known to all team members	Rehearsed procedure
10	The controlled fault and recovery have been rehearsed	Fault-test record
11	Presentation files are available locally	Offline copy
12	Recorded evidence is available as a transparent fallback	Video, logs, and data
13	Adapters, cables, keyboard, mouse, and display interfaces are available	Equipment checklist
14	The demonstration has been completed within the available time	Timed rehearsal

EMBEDDED LINUX Fall 2026

No.	Check	Evidence or status
15	Temporary debugging bypasses have been removed	Release review

12.5.2 The fallback package

A fallback package is not a substitute for attempting the live demonstration. It is evidence that permits technical discussion when an external dependency fails.

A useful fallback package contains:

a short, unedited recording of the system operating;
the software revision used in the recording;
representative raw input and resulting output;
relevant logs with synchronized timestamps;
screenshots or exported plots;
the test conditions and hardware configuration; and
a statement of what the evidence proves and does not prove.

If the live demonstration fails, the student should state the observed symptom without inventing a diagnosis:

The gateway is not currently receiving the uplink. The device log shows that the local measurement and queue are operating, but we have not yet established whether the missing uplink is caused by the radio configuration, gateway availability, or network-server integration. I will use the recorded end-to-end test to explain the verified behaviour and then show how I would distinguish these hypotheses.

This response demonstrates more competence than blaming “the network” without evidence.

Block 213:00–13:50content

Block 2 · 13:00–13:50 · Individual Portfolio and Engineering Evidence

EMBEDDED LINUX Fall 2026

12.6 Architecture Diagrams as Examination Evidence

A strong project should contain at least one system-level block diagram and one more detailed diagram. The diagrams should explain the system immediately, not merely decorate the report.

12.6.1 System-level block diagram

Figure 12.1 illustrates an embedded monitoring and control architecture.

The diagram should be accompanied by explanatory text. Figure 12.1, for example, separates time-critical sampling and safety from Linux-based storage and remote communication. The dashed command path indicates that Linux may request an actuator action, but the microcontroller retains responsibility for local limits and the safe state. This architectural choice reduces dependence on network availability and general-purpose Linux scheduling.

12.6.2 Deployment or trust-boundary diagram

A second diagram may show:

which software runs on each physical machine;
container and process boundaries;

Figure 12.1. Example system architecture with physical, embedded, communication, storage, and user-facing components. Commands pass through the local controller and its interlocks.

wired and wireless links;
protocols and ports;
trusted and untrusted networks;
where credentials are stored;
which component has actuator authority; and
which paths remain available during an outage.

A software architecture diagram should not show a database floating beside an MQTT broker without explaining who writes to it, what schema is used, and what happens when it becomes unavailable.

12.7 Building the Individual Portfolio

The portfolio should be a curated body of evidence, not a directory containing everything produced during the semester. Selection and explanation matter. Each artifact should support a specific claim about the student’s knowledge, skills, or engineering competence.

A strong individual presentation can follow this structure:

problem, stakeholders, environment, and requirements;
system architecture and the student’s personal area of responsibility;
two or three consequential design decisions;
implementation evidence;
verification evidence linked to requirements and learning outcomes;

EMBEDDED LINUX Fall 2026

one failure, diagnostic process, correction, and regression test;
security, reliability, and safety reasoning;
limitations and prioritized improvements; and
individual reflection and professional relevance.

12.7.1 An evidence map

Table 12.4 shows how evidence can be mapped to competence.

Table 12.4. Example individual portfolio evidence map.

ID	Claim	Artifact	What the student explains	Owner
E-01	I can design a supervised Linux service	Unit file, application log, and restart test	Dependencies, identity, permissions, restart limits, and failure visibility	Individual
E-02	I can define a robust data interface	Payload schema and validation tests	Units, timestamp, sequence, version, errors, and compatibility	Individual
E-03	I understand distributed failure	Broker-outage experiment	Timeout, buffering, retry, duplicate handling, and recovery	Individual
E-04	I can integrate hardware safely	Wiring diagram and measured electrical values	Logic voltage, current, pull resistors, driver stage, and safe state	Individual/ shared
E-05	I can evaluate system performance	Latency plot and raw dataset	Measurement method, sample size, percentiles, uncertainty, and limitations	Individual
E-06	I can collaborate professionally	Pull-request review and interface discussion	Feedback given, change accepted or rejected, and effect on integration	Shared with individual attribution

The final column is important. A team diagram can support an individual’s explanation, but it must not be presented as solely individual work unless that claim is true.

12.8 Connecting Evidence to Learning Outcomes

Portfolio evidence is strongest when it connects directly to the learning objectives of the course.

For example:

Table 12.5. Connecting course competence to project evidence.

Course competence	Possible project evidence	Questions the student should answer
Linux architecture	Process tree, system calls, device interface, service dependency diagram	What belongs to the kernel, driver, user space, and application?
Embedded Linux integration	Target image, systemd services, permissions, deployment and boot test	Why is Linux appropriate, and what remains outside Linux?
Hardware interfacing	Wiring, interface timing, calibration, driver code, and failure test	What are the voltage, timing, range, unit, uncertainty, and failure modes?

EMBEDDED LINUX Fall 2026

Course competence	Possible project evidence	Questions the student should answer
Distributed communication	Protocol contract, topic hierarchy, QoS, outage and duplicate tests	What can be delayed, lost, duplicated, or completed after timeout?
Remote management	Authentication, authorization, update and rollback evidence	Who can access what, and how is compromised access revoked?
Version control	Commit history, tags, code review, issue and release records	Can a known release be reconstructed and attributed?
Design-pattern adaptation	Architecture comparison and justified adaptation	Which established pattern was used, and why was it modified?
Cyber-physical system design	End-to-end architecture, safe states, timing, and physical validation	What happens in the physical system when software or communication fails?

The portfolio should not merely contain these artifacts. The student must interpret them. An examiner should be able to ask why a service uses Restart=on-failure, why MQTT QoS 1 can create duplicates, why an I²C bus is unsuitable for a long unprotected cable, or why a watchdog cannot prove complete application health.

12.9 Presenting Engineering Decisions

An engineering decision is more convincing when the alternatives and criteria are visible. The statement “we selected Raspberry Pi because it is powerful” is incomplete. Powerful relative to what, and at what cost?

A decision matrix can make the reasoning explicit. Suppose a team must choose between a Raspberry Pi, ESP32, and STM32 for a gateway and local-control function.

Table 12.6. Example decision matrix; scores range from 1 (poor) to 5 (strong).

Criterion	Weight	Raspberry Pi	ESP32	STM32
Linux libraries and storage	0.25	5	1	1
Deterministic local control	0.20	2	4	5
Integrated wireless access	0.15	4	5	2
Low-power operation	0.15	1	4	5
Remote administration	0.15	5	3	2
Development familiarity	0.10	5	4	3
Weighted score	1.00	3.65	3.25	2.90

If w_i is the weight of criterion i and s_ij is the score of alternative j, the weighted score is

S_j = n ∑ i=1 w_is_ij n ∑ i=1 w_i = 1

According to Table 12.6, the Raspberry Pi is the strongest single gateway candidate under the selected criteria. However, the matrix also reveals its weakness in deterministic control and energy consumption. A heterogeneous solution may therefore be better: a microcontroller maintains local timing and safety, while the Raspberry Pi provides storage, networking, visualization, and remote management.

EMBEDDED LINUX Fall 2026

A decision matrix does not produce objective truth automatically. These scores are illustrative judgements about candidate boards, not universal specifications for processor families. STM32 includes both microcontrollers and microprocessors; the example assumes an STM32 microcontroller board. Exact board models, wireless peripherals, software, and team experience can change the scores. Weights and scores must be justified by requirements or measurements. Changing the criteria could change the result.

12.10 Presenting Experimental Results

Every table and graph should answer a question. It should include:

the variables and units;
hardware and software conditions;
sample count or experiment duration;
treatment of invalid and missing observations;
a comparison or acceptance criterion;
uncertainty or variability where relevant; and
a written interpretation.

For latency measurements t₁, …, t_n, the arithmetic mean is

t̄ = 1/n n ∑ i=1 t_i

but the mean alone may hide rare delays. Embedded and distributed applications often need percentiles such as p₉₅ or p₉₉. A system with a mean latency of 40 ms but a p₉₉ latency of 2.5 s may be unsuitable for an interactive or time-bounded operation.

For an expected sample interval Δt and experiment duration T, the expected sample count is approximately

N_expected = T/Δt

Data completeness can then be reported as

C = 100 N_valid/N_expected %

The calculation is meaningful only if “valid” and the sampling schedule are defined. Count expected scheduled opportunities within an explicit interval, such as [t₀, t₀ + T]; including both endpoints can otherwise add one sample. Count at most one valid record per scheduled opportunity. A received JSON object is not necessarily a valid physical measurement. Validation may require a correct schema, known device identity, acceptable timestamp, plausible range, valid sensor status, and no duplicate event identity.

Figures require interpretation

Do not end a paragraph with “the results are shown in Figure 5.” Explain the pattern, compare it with the requirement, identify anomalies, and state what conclusion is supported. The explanation is part of the engineering evidence.

Block 314:00–14:50content

Block 3 · 14:00–14:50 · Professional Engineering Practice and Reproducibility

EMBEDDED LINUX Fall 2026

12.11 Reporting Failure Honestly

Failure does not automatically indicate weak work. An unexplained or concealed failure does.

A technically valuable failure report contains:

the expected behaviour;
the actual behaviour;
the exact test condition;
preserved logs, data, or observations;
competing hypotheses;
experiments used to distinguish the hypotheses;
the most strongly supported cause;
corrective action, if completed;
regression evidence; and
remaining uncertainty.

Consider a LoRaWAN sensor that successfully joins the network but produces no application data. Possible causes include:

the node did not transmit after joining;
regional radio parameters were incorrect;
the gateway did not receive the uplink;
the network server rejected the frame counter;
the application payload decoder failed;
the integration credentials were incorrect; or
data arrived but was rejected by the private-cloud schema.

Restarting every device may temporarily remove the symptom but does not identify the cause. A better investigation follows the message across each boundary and records where evidence stops.

12.11.1 What worked, what did not, and why

A mature discussion can distinguish three categories:

Worked and verified: the behaviour met a measurable criterion under recorded conditions.

Partially worked: the central function operated, but performance, reliability, or integration remained below the requirement.

Not achieved: the function was incomplete or failed its acceptance test.

For example:

The system recorded valid local measurements throughout the field test, satisfying R-03. Automatic cloud recovery was only partially achieved: queued messages were delivered after reconnection, but 17 duplicate records were created because the database lacked an idempotency key. The duplicates were preserved as evidence. The proposed correction is a unique constraint on device ID, session ID, and sequence number combined with conflict-safe insertion.

This paragraph demonstrates more engineering understanding than simply stating that MQTT QoS 1 is reliable.

EMBEDDED LINUX Fall 2026

12.12 Technical Questioning

Technical questioning evaluates whether the student understands the system beyond prepared slides. Questions may move across abstraction levels. A student discussing an MQTT dashboard may be asked about the sensor’s electrical interface, Linux process supervision, network outage behaviour, data units, or client authorization.

A useful response structure is:

answer the question directly;
state important assumptions;
refer to a specific architecture element or evidence item;
explain the relevant trade-off or limitation; and
say how the claim could be tested if uncertainty remains.

For example:

We selected MQTT QoS 1 because losing a measurement was considered more harmful than receiving it twice. QoS 1 provides at-least-once delivery for a completed protocol exchange, so the application cannot assume uniqueness. We therefore attach the device ID, a session ID, and a sequence number that increases within that session, and apply an idempotency constraint in storage. Test T-14 shows that replaying the same message three times creates only one stored record.

12.12.1 Responding when the answer is uncertain

It is acceptable not to remember every command, register address, or protocol constant. It is not acceptable to replace missing knowledge with confident invention.

A professional response may be:

I do not remember the exact maximum current from the datasheet. In our design, we used the measured operating current and the manufacturer’s stated maximum to size the regulator with margin. I would verify the exact value in the referenced datasheet before changing the power design.

This response demonstrates safety awareness and appropriate use of evidence.

12.12.2 Common questioning mistakes

answering a different question because it matches a rehearsed slide;
describing what the code does without explaining why;
claiming that a library, framework, or protocol guarantees complete system safety;
confusing a successful packet with a correct physical measurement;
using “real time” to mean only “fast”;
treating encryption as equivalent to authorization;
describing team work as personal work;
blaming hardware or networking without diagnostic evidence; and
refusing to acknowledge limitations.

EMBEDDED LINUX Fall 2026

12.13 Questions Relevant to Employment Interviews

The portfolio can also prepare students for technical employment interviews. Employers commonly ask candidates to explain a project deeply rather than list technologies.

A useful two-minute project explanation includes:

the real problem and user;
the system architecture;
the student’s personal responsibility;
the most difficult engineering problem;
one measured result;
one failure and what was learned; and
what would be changed for deployment.

Instead of saying:

We used Raspberry Pi, Python, Docker, MQTT, LoRaWAN, ROS 2, and artificial intelligence.

a stronger response is:

I designed the gateway service that validated measurements from six wireless nodes, stored them locally during network outages, and forwarded them to MQTT after reconnection. My main challenge was preventing duplicate database effects under QoS 1. I introduced a device, session, and sequence idempotency key and verified it using replay and broker-restart tests. The current limitation is that the queue has only been tested for eight-hour outages.

The second response demonstrates ownership, understanding, verification, and honest scope.

12.14 Professional Presentation of Code

Complete source code belongs in the submitted archive and, where appropriate, in appendices. The oral presentation should show only the code needed to support a particular explanation.

A useful code extract might demonstrate:

input validation;
safe-state enforcement;
sequence and timestamp handling;
bounded retry with backoff;
exception handling and structured logging;
service shutdown;
authorization;
protocol decoding; or
a regression test.

The student should explain both behaviour and design intent.

EMBEDDED LINUX Fall 2026

Listing 12.1. Example of bounded reconnect behaviour

1	import random
2	import time
3	import logging
4	import math
5
6	logger = logging.getLogger(__name__)
7
8	def reconnect(connect, attempts=6, base_delay=1.0):
9	"""Attempt reconnection with bounded exponential backoff."""
10	if type(attempts) is not int or not 1 <= attempts <= 20:
11	raise ValueError("attempts must be an integer from 1 to 20")
12	if type(base_delay) not in (int, float):
13	raise ValueError("base_delay must be numeric")
14	if not 0.0 < base_delay <= 30.0 or not math.isfinite(base_delay):
15	raise ValueError("base_delay must be in (0, 30] seconds")
16	for attempt in range(attempts):
17	try:
18	return connect()
19	except ConnectionError as error:
20	final_attempt = attempt + 1 == attempts
21	ceiling = min(30.0, base_delay * (2 ** attempt))
22	delay = 0.0 if final_attempt else random.uniform(0.5 * ceiling, ceiling)
23	logger.warning(
24	"connection_failed",
25	extra={
26	"attempt": attempt + 1,
27	"maximum": attempts,
28	"retry_delay_s": round(delay, 2),
29	"error_type": type(error).__name__,
30	},
31	)
32	if final_attempt:
33	raise RuntimeError("dependency unavailable after bounded retries") from error
34	time.sleep(delay)

The connect callback must use its own finite connection and handshake timeouts and return only when the connection is established; it must raise ConnectionError for the transient failures that this wrapper may retry. Library-specific exceptions may need an adapter. Authentication or configuration errors should normally propagate without retry. Bounding the number of attempts does not bound total time if a single connection attempt can block forever. Configure the logging formatter to expose the structured fields, and avoid placing credentials in exception messages.

This extract is useful only if the student can explain:

why retries are bounded;
why exponential backoff is used;
why jitter is added;
which errors should not be retried;
what the calling service does after final failure; and
how this behaviour was tested without waiting for long real-time delays.

A screen containing 200 unexplained lines of code is weak evidence.

12.15 Security, Privacy, and Responsible Disclosure

A portfolio should demonstrate security decisions without exposing operational secrets. Before submission, search the archive for:

EMBEDDED LINUX Fall 2026

passwords and password hashes;
API keys and access tokens;
private SSH or TLS keys;
Wi-Fi credentials;
database connection strings;
session cookies;
LoRaWAN root or application keys;
precise private infrastructure addresses;
personal information; and
location histories that could expose people or valuable assets.

Replace secrets with documented placeholders:

Listing 12.2. Configuration template without secrets

1	MQTT_HOST=mqtt.example.invalid
2	MQTT_PORT=8883
3	MQTT_USERNAME=replace_at_deployment
4	MQTT_PASSWORD_FILE=/run/secrets/mqtt_password
5	DEVICE_ID=node-07
6	TLS_CA_FILE=/etc/eml/certs/ca.pem

Do not delete all security configuration merely to avoid exposing credentials. The archive should show how secrets are supplied, which identity uses them, how permissions are restricted, and how credentials can be rotated or revoked.

If testing reveals a security weakness, describe it responsibly. Do not publish credentials, exploit unrelated systems, or attack infrastructure without authorization.

12.16 Reproducibility and the Final Archive

A project is reproducible when another technically qualified person can reconstruct its essential behaviour using the documented hardware, software, configuration, and procedure. Reproducibility does not mean that every dependency must be bundled into the archive. It means that dependencies are identified, versioned, obtainable, and connected through clear instructions.

A strong archive contains:

final report and individual portfolio;
source code with repository history or an identifiable release;
bill of materials with exact models and quantities;
wiring, pin allocation, and power information;
mechanical or enclosure files where relevant;
operating-system and target-hardware information;
package and dependency versions;
systemd units, container definitions, and installation scripts;
interface contracts and payload schemas;
configuration templates without secrets;
sample and raw data supporting reported claims;
test specifications and test results;
user manual and maintenance instructions;
known limitations and unresolved issues;
licenses and attribution for reused material; and
a checksum manifest.

EMBEDDED LINUX Fall 2026

12.16.1 Recommended archive structure

Listing 12.3. Example final project archive

1	field-monitor/
2	\|-- README.md
3	\|-- LICENSES/
4	\|-- report/
5	\| \|-- final-report.pdf
6	\| `-- source/
7	\|-- portfolio/
8	\| \|-- student-a/
9	\| \|-- student-b/
10	\| `-- student-c/
11	\|-- hardware/
12	\| \|-- bom.csv
13	\| \|-- wiring.pdf
14	\| \|-- pinout.md
15	\| `-- enclosure/
16	\|-- software/
17	\| \|-- acquisition/
18	\| \|-- gateway/
19	\| \|-- visualization/
20	\| `-- tests/
21	\|-- deployment/
22	\| \|-- install.sh
23	\| \|-- systemd/
24	\| \|-- containers/
25	\| `-- config.example/
26	\|-- interfaces/
27	\| \|-- payload-schema.json
28	\| \|-- mqtt-topics.md
29	\| `-- api-contract.yaml
30	\|-- evidence/
31	\| \|-- raw-data/
32	\| \|-- processed-data/
33	\| \|-- logs/
34	\| \|-- plots/
35	\| `-- test-results/
36	\|-- user-manual/
37	\|-- KNOWN-ISSUES.md
38	\|-- CHANGELOG.md
39	`-- SHA256SUMS

The root README.md should explain the project, identify the release, list prerequisites, provide the shortest verified reconstruction path, and link to detailed instructions.

12.16.2 Checking archive integrity

A checksum helps reveal accidental change or incomplete transfer:

Listing 12.4. Creating and verifying an archive checksum manifest

1	# Run in the prepared release directory on GNU/Linux.
2	set -euo pipefail
3	find . -type f ! -path ./SHA256SUMS -print0 \
4	\| LC_ALL=C sort -z \
5	\| xargs -0 -r sha256sum > SHA256SUMS
6
7	sha256sum --check SHA256SUMS

A checksum detects modification but does not prove authorship or protect against a maliciously replaced checksum file. This example hashes regular files; inventory symbolic links separately or exclude them deliberately, and verify that the expected file list is complete. A checksum check does not report newly added files. Signed releases or trusted repository tags provide stronger provenance.

Block 415:00–15:50content

Block 4 · 15:00–15:50 · Showcase, Portfolio Clinic and Assessment

EMBEDDED LINUX Fall 2026

12.17 The User Manual and Engineering Handover

The user manual is written for the operator, while the reconstruction guide is written for a technical successor. These are not the same document.

The operator manual should explain:

intended use and prohibited use;
startup and shutdown;
normal indicators;
alarm and degraded states;
routine operation;
safe handling;
data retrieval;
basic troubleshooting;
maintenance intervals; and
when to stop and contact technical support.

The technical handover should additionally explain:

architecture and interfaces;
installation and configuration;
exact component models and substitutions;
calibration;
deployment and rollback;
backup and restoration;
credential provisioning and rotation;
diagnostic commands;
test execution;
known defects; and
future development priorities.

An operator should not need root access or Linux commands for ordinary use. If normal use requires repeated manual SSH sessions, the system is still being operated as a development prototype rather than a finished client appliance.

12.18 Common Weaknesses in Project Presentations

Table 12.7 summarizes frequent weaknesses and stronger alternatives.

Table 12.7. Common weaknesses and stronger presentation practices.

Weak approach	Why it is weak	Stronger alternative
Long background before showing the system	Consumes time without establishing technical achievement	State the need briefly and show the architecture and end-to-end path

EMBEDDED LINUX Fall 2026

Weak approach	Why it is weak	Stronger alternative
Listing technologies	Does not demonstrate why or how they were used	Explain responsibilities, interfaces, decisions, and measured behaviour
“Everything worked”	Suggests weak testing or concealed limitations	Show acceptance results, failures, corrections, and remaining risks
Dashboard-only demonstration	A user interface may hide missing data or failed dependencies	Show physical input, internal health, stored evidence, and output
Screenshots without context	Cannot establish conditions, revision, timing, or reproducibility	Annotate the evidence and preserve the underlying data and logs
Complete terminal transcript	Important evidence becomes difficult to locate	Show the relevant line and explain what it proves
Team contribution described as “we did everything together”	Prevents individual assessment	Identify ownership, review, interfaces, and attributable evidence
Blaming hardware	Does not demonstrate diagnosis	Present observations, hypotheses, tests, and remaining uncertainty
Claiming industrial readiness	A classroom prototype rarely satisfies certification and lifecycle needs	State the tested maturity and steps required for deployment

12.19 Guided Laboratory: Showcase and Portfolio Clinic

Guided laboratory: showcase and portfolio clinic

Each team shall prepare and deliver a timed end-to-end demonstration using the intended release and target hardware.

The demonstration must include:

the problem and one principal acceptance criterion;
a system-level block diagram;
the complete input-to-output path;
one quantitative result;
one controlled failure or degraded mode;
one important engineering decision;
one limitation; and
identification of the supporting archive evidence.

A peer team shall review the project using the following questions:

Was the main requirement demonstrated?
Could the observed result be independently verified?
Were unsafe states or security boundaries ignored?
Was the controlled fault detected and handled?
Were limitations reported honestly?
Could another engineer reconstruct the system?

After the team demonstration, each student shall present one individually owned design decision and answer technical questions about its interface, failure behaviour, verification,

EMBEDDED LINUX Fall 2026

security, and alternatives. Feedback must be converted into specific technical actions rather than cosmetic slide changes alone.

12.20 Portfolio Evidence

Portfolio evidence

The final individual portfolio should contain or reference:

a concise statement of the student’s personal role;
a system architecture diagram with the owned boundary highlighted;
two or three significant design decisions;
attributable source code, configuration, hardware, or analysis;
a requirement-to-evidence map;
at least one measured result with interpretation;
one failure investigation and regression test;
security, reliability, safety, and privacy reasoning;
limitations and prioritized future improvements;
collaboration evidence such as commits or code reviews; and
an individual reflection explaining how the student’s engineering judgment developed.

Every artifact must be labeled as individual, shared, externally sourced, or adapted. The student must be able to explain all evidence used to support personal competence.

12.21 Self-Assessment and Interview Questions

The following questions are designed both for the Embedded Linux course and as preparation for technical employment interviews. Students should first answer without consulting the text and then compare their reasoning with the suggested answers.

12.21.1 Questions

Q1. Why is a successful live demonstration insufficient evidence that an embedded system is reliable?

Q2. What is the difference between demonstrating a feature and verifying a requirement?

Q3. How should a student distinguish team output from individual achievement?

Q4. Why should the main end-to-end function be demonstrated before optional features?

Q5. Give three appropriate controlled faults for an embedded monitoring system.

Q6. Why can a recorded video be useful but insufficient as the only demonstration evidence?

Q7. What should a student say when a live system fails for an unknown reason?

Q8. Why is showing an entire source file usually weak presentation practice?

Q9. What information must accompany a graph of system latency?

Q10. Why can mean latency be misleading?

Q11. Explain why a failed test can strengthen a project report.

Q12. What evidence would demonstrate that an acquisition system tolerates a temporary network outage?

Q13. What does an MQTT QoS 1 delivery guarantee imply for application design?

Q14. Why does encryption not automatically provide authorization?

Q15. What is the difference between an operator manual and a reconstruction guide?

EMBEDDED LINUX Fall 2026

Q16. Why should configuration templates be included without operational secrets?

Q17. What does a checksum manifest establish, and what does it not establish?

Q18. How would you answer an examiner who asks for a technical value you cannot remember?

Q19. Why is “we divided the work equally” inadequate evidence of individual competence?

Q20. Give a professional two-minute explanation of your own project.

12.22 Suggested Answers

A1.A short successful demonstration covers only limited conditions. It does not establish behaviour during long operation, power loss, dependency failure, malformed input, resource exhaustion, security attacks, or environmental variation. Reliability requires defined conditions, repeated tests, measurements, and recovery evidence.

A2.A feature demonstration shows that an observable function occurred. Requirement verification compares measured behaviour with a predefined, measurable acceptance criterion under controlled conditions.

A3.Shared architecture and integration results should be labeled as team work. The student should identify personally owned decisions, commits, code, hardware, tests, analyses, reviews, and explanations. Individual competence is demonstrated through attributable evidence and understanding.

A4.The end-to-end path establishes that the central purpose of the project works across subsystem boundaries. Optional features are not valuable if the physical input, processing, communication, storage, and useful output are not integrated.

A5.Suitable examples include disconnecting a sensor, blocking broker connectivity, terminating a supervised service, injecting a malformed payload, presenting stale data, or causing a command timeout. The fault must be safe and have bounded consequences.

A6.A video can preserve evidence when external infrastructure fails, but it does not by itself establish the current release, configuration, completeness, or reproducibility. It must be accompanied by data, logs, conditions, and version information.

A7.State the observed symptom, distinguish it from possible causes, show the evidence currently available, and describe the next diagnostic test. Do not guess confidently or blame a subsystem without evidence.

A8.An entire file is difficult to read and obscures the important design decision. A short extract linked to the complete archived source allows the student to explain validation, failure handling, concurrency, security, or another specific engineering property.

A9.The graph needs variables, units, hardware and software conditions, sample size, collection method, treatment of invalid observations, statistical summary, and a comparison with the relevant requirement.

A10.Rare delays may be important even when the mean is low. Percentiles such as p₉₅ and p₉₉ expose tail behaviour that may dominate interactive, control, or deadline-sensitive performance.

A11.A documented failed test reveals the boundary of the design and can demonstrate strong diagnosis and engineering judgment. Concealing or deleting the result would make the report less credible.

A12.Evidence should show that acquisition continued locally while connectivity was unavailable, storage remained within capacity, the queue was bounded, reconnection used an appropriate policy, and retained records were delivered without unintended duplicate effects after recovery.

A13.QoS 1 provides at-least-once delivery at the MQTT exchange level. A message may be delivered more than once, so application-level operations must tolerate duplicates through sequence numbers, event identifiers, or idempotent storage.

A14.Encryption alone protects confidentiality; an authenticated protocol such as properly configured TLS also protects integrity in transit. Authorization determines what an authenticated

EMBEDDED LINUX Fall 2026

identity is permitted to do. An encrypted connection can still give an authenticated user excessive privileges.

A15.The operator manual explains safe routine use, indicators, shutdown, data retrieval, and basic troubleshooting. The reconstruction guide explains hardware assembly, installation, configuration, deployment, testing, maintenance, and recovery for a technical successor.

A16.Templates make deployment reproducible while preventing accidental disclosure. They should document variable names, file locations, types, and provisioning methods without containing actual passwords, keys, or tokens.

A17.A checksum manifest detects accidental or unauthorized modification relative to the recorded digest. An unsigned checksum file does not prove authorship because an attacker could replace both the artifact and its checksum.

A18.State that the exact value is not remembered, explain how it influenced the design, identify the authoritative source, and describe how it would be verified before making a decision. Do not invent a value.

A19.Equal task division does not reveal which decisions or technical competencies belong to each student. Assessment requires specific, attributable evidence and the ability to explain personal and shared work.

A20.A strong response identifies the user problem, architecture, personal responsibility, difficult decision, measured result, failure or limitation, and next improvement. It explains engineering reasoning rather than merely listing technologies.

12.23 Final Reflection Questions

Before submission, each student should be able to answer the following questions in their own words:

Which decision in the project had the greatest effect on reliability?
Which assumption was shown to be incorrect?
Which failure produced the most useful learning?
Which component would become the first bottleneck if the system were scaled?
Which security control would be essential before real client deployment?
Which part of the system can continue operating when the network fails?
Which claim in the report has the strongest evidence?
Which claim has the weakest evidence?
What would another engineer find most difficult to reproduce?
What would you redesign if the project started again?

The answers should be specific to the implemented project. Generic statements such as “we learned teamwork” or “more time would improve the system” provide little evidence of engineering development.

12.24 Chapter Summary

Chapter summary

A professional demonstration is a structured engineering argument supported by requirements, measurements, architecture, and reproducible evidence. It begins with the client need and core end-to-end function, then demonstrates performance, failure handling, limitations, and recovery.

EMBEDDED LINUX Fall 2026

The team project provides a shared technical environment, but each student must demonstrate individually attributable knowledge, skills, decisions, implementation, testing, and reflection. Good evidence is specific, versioned, measurable, interpretable, and honest about its limits.

A failed test is not automatically a failed project. Unexplained claims, concealed limitations, missing ownership, and unreproducible results are more serious weaknesses. The strongest students can explain not only what their system does, but why it was designed that way, how it was verified, where it can fail, and what must change before deployment.

The official examination is an individual presentation portfolio graded using the Danish 7-point grading scale. The project is the setting in which competence is developed; the individual portfolio and technical discussion are where each student demonstrates that competence.

Summary

The chapter presents a practical framework for demonstrating an Embedded Linux project as engineering evidence rather than as a simple working prototype. Students learn to design a short, structured demonstration, show controlled failures and recovery, prepare for demonstration day, and connect system architecture and experimental results to individual responsibility. The chapter also develops the individual portfolio through attributable evidence, engineering decisions, honest failure reporting, technical questioning, professional code presentation, security and responsible disclosure, reproducibility, final archiving, user documentation, engineering handover, and reflective assessment.

Course outline

What we will learn

From Linux foundations to physical interfaces, networking, security and a complete embedded system.

Linux foundationsKernel, users, processes and file systems

Command lineShells, scripting and automation

Embedded hardwareBoot, storage and device drivers

Physical I/OGPIO, sensors and actuators

Device busesUART, I²C and SPI

NetworkingTCP/IP, SSH and remote management

Distributed systemsMessage passing and cooperating nodes

Engineering practiceGit, testing, logging and deployment

SecurityLeast privilege, updates and secrets

Teaching method

Short introductions are followed by laboratory activities. Work is normally completed in teams of three. Each team develops an embedded Linux system; the examination portfolio is individual.

Project ideas

Applications you could build

Each project should begin with one reliable end-to-end function.

Automatic Raspberry Pi-based GPS trackerSample examination report available in PDF format

Environmental monitoring stationValidated sensing, local storage and dashboard

Energy monitoring systemMeasure, log and visualize equipment power use

Greenhouse automationClimate sensing, actuation and remote supervision

Field-robot telemetryLocation, operating state, measurements and faults

LoRaWAN sensor networkField nodes, TTN integration and private cloud

Intelligent irrigationSensing, decisions, valves and safe failure handling

Multi-node IoT gatewayProtocol translation, buffering and secure forwarding

ROS 2 communication systemDistributed nodes, QoS and service integration

Edge-AI monitoring systemLocal inference, measured performance and safe fallback

A complete project should demonstrate

NeedA clear user and purpose

Physical interfaceA sensor, actuator or device

Linux integrationPrograms, scripts or services

CommunicationA justified data-exchange method

ReliabilityLogging and failure handling

EvidenceTests, results and reflection

Contractor and client roles

Project groups

Each group develops a project for one client group and evaluates the project received from another contractor group.

Contractor

Heros

ProjectProject 01

Delivers to: Client not assigned
Receives from: Contractor not assigned

Fridays · four 50-minute slots · Odense

Fall 2026 lecture plan

The SDU timetable remains authoritative for dates, times and rooms.

No.	Date	Lecture topic
01	04 Sep 2026	Linux fundamentals and development environment
02	11 Sep 2026	Embedded Linux Platforms, Raspberry Pi, Services, and Automation
03	18 Sep 2026	Distributed Networking, Web Services, Monitoring, and Remote Management
04	25 Sep 2026	Sensors, Actuators, GPIO, and Serial Interfaces
05	02 Oct 2026	Microcontrollers and Distributed Embedded Nodes
06	09 Oct 2026	Wireless Acquisition, LoRa Peer-to-Peer, and MQTT
07	23 Oct 2026	LoRaWAN, TTN, Gateways, Tracking, and Private-Cloud Integration
08	06 Nov 2026	ROS 2: Robot Integration, Simulation, and Deployment
09	13 Nov 2026	Home Assistant, Edge AI, Local LLMs, and Intelligent Systems
10	20 Nov 2026	Project Integration, Security, and Verification
11	27 Nov 2026	Implementation, Debugging, and Deployment
12	04 Dec 2026	Demonstrations and the Individual Portfolio

Project progression

Project ideas and proposals begin in Module 1 and evolve throughout the course. Module 10 is the formal integration, architecture and verification review; Modules 11–12 complete implementation, demonstration and individual portfolio evidence.

Lecture 12 · participation

Student questions

Questions remain hidden until the student is called. Model answers are revealed separately.

Instructor classroom view

The roster, answers, attendance and participation records are available only to the authorized primary owner after sign-in.

Instructor sign in

Definitions

Essential course vocabulary

Plain-language definitions for the technical terms used throughout the course.

Term	Definition	Example
Actuator	A device that produces a physical action.	Motor, valve, relay or fan
Boot	The sequence that starts the hardware, kernel, services and applications.	Starting an embedded computer
CLI	A text interface that accepts commands.	Windows Terminal or a Linux terminal
Command	An instruction interpreted by a shell.	pwd, ls or Get-Location
Device driver	Software through which the operating system communicates with hardware.	GPIO or camera driver
Directory	A named container for files and other directories.	/home/student/eml
Distribution	A complete operating system built around the Linux kernel.	Ubuntu or Debian
Embedded system	A computer integrated into a larger product for a defined purpose.	Greenhouse controller
File system	The structure used to name, store and retrieve files.	ext4
GPIO	A configurable digital input or output pin.	Reading a switch
I²C	A two-signal serial bus for peripherals.	Environmental sensor
Kernel	The privileged core managing memory, processors, devices and processes.	Linux kernel
MQTT	A lightweight publish/subscribe messaging protocol.	Sending sensor data
Process	A running instance of a program.	A data logger
PWM	Rapid switching used to control average power or a signal duty cycle.	Motor speed
Root	The privileged Linux user or the top directory, depending on context.	Administrative access
Script	A file containing commands that automate work.	A backup script
Sensor	A device that converts a physical quantity into data.	Temperature sensor
Service	A background program providing an ongoing function.	SSH server
Shell	A program that interprets commands and starts programs.	Bash or PowerShell
SPI	A synchronous bus commonly used for fast peripherals.	Display or converter
SSH	Encrypted remote command-line access.	Managing a Raspberry Pi
TCP/IP	The principal protocol family used across computer networks.	Device-to-server communication
UART	An asynchronous serial interface.	Debug console
User space	The environment where ordinary programs run outside the kernel.	Application software
Version control	A system that records and manages file changes.	Git

Official examination information · EKA T550077102

Individual portfolio examination

Form

Portfolio

Individual presentation portfolio submitted at semester end.

Grade

7-point scale

No second examiner.

Weighting

No split published

No separate written-exam or coursework percentages are stated.

Re-examination

Same form

Same form as the ordinary examination.

Team project and individual assessment

The team project creates practical evidence, but each student is assessed individually through the presentation portfolio. Classroom participation points support engagement and do not form part of the official grade.