Bachelor Program in Mechatronics Engineering
Internet of Things in Mechatronics
•
Bachelor
Integrated IoT Mechatronics Capstone
Introduction and Context
An IoT mechatronics capstone integrates mechanical structure, sensors, actuators, embedded control, communications, data systems, cybersecurity, and human decision-making into one operational product or service. Unlike an isolated laboratory exercise, a capstone must satisfy competing requirements: it must work reliably, be safe to operate, be economically defensible, protect data, support maintenance, and communicate its value to technical and non-technical stakeholders.
The capstone is therefore an engineering systems project rather than merely a programming or prototype-building task. The central design question is not “Can a device be connected to the internet?” but “What measurable problem is solved, for whom, under what constraints, and with what evidence?”
A typical solution contains five interacting layers:
Physical layer: mechanisms, structures, motors, valves, tools, materials, and the operating environment.
Sensing and actuation layer: transducers, signal conditioning, motor drivers, relays, pneumatic components, and local controllers.
Edge-control layer: microcontrollers or industrial computers that acquire data, execute control logic, buffer messages, and provide local safety responses.
Network and platform layer: wired or wireless communication, message brokers, databases, dashboards, and device-management services.
Application and stakeholder layer: alerts, analytics, maintenance workflows, reports, operator interfaces, and business decisions.
The layers must be designed together. A high-resolution sensor is of little value if its data cannot be trusted; a cloud dashboard is ineffective if a machine must remain safe during network loss; and an accurate predictive model is not useful if maintenance staff cannot act on its recommendation.
Learning Objectives
After completing this chapter, a student should be able to:
translate stakeholder needs into verifiable system requirements;
develop an architecture linking mechanical, electrical, computational, and cloud components;
select sensors, actuators, networks, and data structures using engineering criteria;
implement local control, telemetry, alerts, and fault handling;
apply threat modeling and security controls to an IoT mechatronic system;
design verification, validation, commissioning, and acceptance tests;
evaluate cost, energy, safety, ethics, sustainability, and maintainability;
present technical evidence and a professional business case.
From Stakeholder Need to System Requirement
Capstone projects commonly fail because teams begin with available hardware instead of a clearly defined problem. A disciplined project begins with stakeholder discovery. Stakeholders may include operators, maintenance technicians, production managers, customers, safety personnel, information-technology staff, regulators, and affected members of the public.
A useful requirement has five characteristics: it identifies the required behavior, includes measurable performance, specifies operating conditions, identifies the responsible subsystem, and defines how compliance will be demonstrated. For example, “the system shall monitor temperature” is incomplete. A stronger requirement is: “The system shall measure enclosure temperature from 0 °C to 60 °C with an accuracy of ±1 °C, record a timestamped value at least every 10 s, and generate a local alarm when temperature exceeds 50 °C.”
Requirements should be classified as:
Category
Example
Functional
Start a pump when tank level is below the lower threshold.
Performance
Report level within 5 s of a significant change.
Safety
Stop motion when the guard is opened.
Security
Authenticate every remote command.
Interface
Display current state and alarm history to an operator.
Economic
Keep prototype bill of materials below a defined limit.
Sustainability
Minimize standby energy and enable component replacement.
Regulatory
Conform to applicable electrical, machinery, radio, and data-protection rules.
A requirements traceability matrix links each requirement to its design element, test method, result, and approval. This prevents attractive demonstrations from hiding untested functions.
System Architecture and Design Logic
A robust architecture separates time-critical safety and control from non-critical monitoring and analytics. Local control should continue when the cloud, dashboard, or internet connection is unavailable. Remote services should improve supervision and analysis, not become the only means of preventing injury or equipment damage.
Layered IoT mechatronics architecture
Figure: Layered IoT mechatronics architecture
Figure: A layered architecture in which local control and safety remain active while platform services provide monitoring and analysis.
Measurement, Control, and Data Quality
Sensor selection requires consideration of range, accuracy, resolution, repeatability, response time, environmental rating, calibration drift, installation, and failure behavior. Resolution is not the same as accuracy: a sensor may report many decimal places while being systematically wrong.
For a measured variable, a simple calibration model is often written as:
y = ax + b
Here, x is the raw sensor value, y is the estimated physical quantity, a is the scale factor, and b is the offset. The model is appropriate only over the calibrated operating range and when a linear approximation is justified. Calibration must document reference instruments, environmental conditions, uncertainty, and date.
Sampling must be fast enough to represent the physical process. If a signal contains meaningful frequency components up to fmax, ideal sampling requires a frequency greater than 2fmax; this is the Nyquist condition. In practical systems, an engineering margin and an anti-aliasing filter are required because real signals and filters are not ideal.
A feedback controller compares a reference value with a measured value. The error is:
e(t) = r(t) − y(t)
where r(t) is the desired value and y(t) is the measured output. A proportional controller is:
u(t) = Kp e(t)
where u(t) is the control command and Kp is the proportional gain. Proportional control is simple but may leave a steady-state error. Integral action can remove persistent error, but excessive integral action may cause windup and overshoot. In a capstone, safety interlocks, output limits, rate limits, and a defined response to invalid sensor data are often more important than sophisticated control algorithms.
Data quality rules should identify missing, stale, out-of-range, duplicated, physically impossible, and conflicting values. Every record should have a timestamp, unit, device identity, and quality status. Time synchronization is essential when correlating vibration, current, and temperature data from multiple devices.
Communication and Edge–Cloud Allocation
Communication choices should reflect range, bandwidth, latency, power, reliability, installation environment, and security. Ethernet may offer predictable performance; Wi-Fi provides flexibility but can be sensitive to coverage and congestion; low-power wide-area technologies support small messages over long distances; industrial fieldbuses can provide deterministic local control. The best choice is often hybrid.
Message design should be explicit. A telemetry message might contain device identifier, schema version, timestamp, measurement name, value, unit, quality flag, and sequence number. Commands require stronger controls: authenticated origin, authorization, expiry, replay protection, acknowledgement, and a safe response if execution fails.
The edge should perform immediate control, safety logic, signal filtering, temporary storage, and basic diagnostics. The platform is well suited to historical storage, fleet comparison, dashboards, long-term analytics, and controlled software updates. Sending every raw sample to the cloud is not automatically superior; it may increase cost, bandwidth, energy use, and privacy exposure.
Cybersecurity, Safety, and Resilience
IoT security is a systems responsibility. A threat model identifies assets, actors, attack paths, consequences, and mitigations. Relevant assets include firmware, credentials, sensor data, command channels, production information, personal data, and physical equipment.
Core controls include unique device identities, secure credential storage, least-privilege permissions, encrypted communication, signed firmware, secure boot where supported, network segmentation, logging, vulnerability management, backup, and a tested update process. Default passwords and shared administrator accounts should not be used. Security monitoring must also account for physical access to controllers and exposed communication ports.
Safety and cybersecurity overlap but are not identical. A malicious command may create a safety hazard, but a failed bearing or broken wire can also create danger without any cyberattack. A safety analysis should identify hazards, causes, consequences, safeguards, and residual risk. Emergency stops, guards, limit switches, thermal cut-outs, and safe energy isolation should be implemented independently of ordinary cloud logic where necessary.
A useful risk-prioritization model is:
R = P × S
where R is a qualitative or semi-quantitative risk score, P is the likelihood rating, and S is the severity rating. The multiplication is a prioritization aid, not a universal physical law; rating scales must be defined consistently, and high-severity hazards should not be accepted merely because their estimated probability is low. Applicable machinery, electrical, radio, occupational-safety, and data-protection requirements must be identified for the project jurisdiction.
Resilience includes graceful degradation. During network failure, the system should maintain safe local operation, indicate loss of connectivity, buffer data where feasible, and prevent uncontrolled automatic recovery. After restart, it should establish a known state rather than blindly repeating stale commands.
Implementation and Engineering Workflow
A practical capstone workflow is iterative:
Define the problem, stakeholders, assumptions, constraints, and success criteria.
Produce a concept architecture and compare alternatives.
Build a minimum viable physical and digital prototype.
Test interfaces independently before full integration.
Add fault handling, security controls, and user workflows.
Conduct verification and validation with recorded evidence.
Review cost, sustainability, safety, and maintainability.
Demonstrate the system and present limitations honestly.
Version control should cover firmware, configuration, dashboard definitions, interface specifications, test scripts, and documentation. Configuration must be separated from source code where practical, with secrets excluded from repositories. A reproducible build and a labeled release reduce uncertainty during demonstration and maintenance.
Interfaces should be specified before integration. For each connection, document electrical levels, pin assignments, units, message schema, timing, error codes, ownership, and test method. Mechanical interfaces also require tolerances, loads, fastening, access, and replacement procedures.
Verification, Validation, and Acceptance
Verification asks whether the system was built according to its specifications. Validation asks whether it solves the stakeholder’s real problem. Both are necessary. A system can pass a software unit test and still fail validation because the operator cannot interpret its alarms.
Test levels include unit tests, integration tests, hardware-in-the-loop tests, environmental tests, security tests, usability tests, endurance tests, and acceptance demonstrations. Each test should state preconditions, equipment, steps, expected result, actual result, evidence, and pass/fail decision.
Useful performance measures include availability, latency, false-alarm rate, missed-event rate, energy consumption, measurement error, recovery time, and maintenance time. For a set of n measured values, mean absolute error can be calculated as:
MAE = (1/n) ∑|yi − ŷi|
Here, yi is the reference value, ŷi is the system estimate, and n is the number of observations. Both values must use the same units, and the reference must be sufficiently more accurate than the device under test for the comparison to be meaningful.
For availability over an observation period:
A = Tup / (Tup + Tdown)
where Tup is operating time and Tdown is downtime under the agreed definition. Planned maintenance, communication outages, and safety shutdowns must be classified consistently; otherwise, availability figures are misleading.
Economic, Sustainability, and Professional Evaluation
Economic evaluation should include acquisition, installation, integration, training, maintenance, connectivity, software, energy, replacement, and disposal costs. A low-cost prototype may become expensive if it requires frequent recalibration or proprietary services.
For a simple investment estimate, payback period is:
Payback period = Initial investment / Annual net benefit
This approximation assumes a reasonably stable annual net benefit and ignores the time value of money. It should not replace a discounted cash-flow analysis for major investments. Benefits must be evidenced: reduced downtime, lower energy use, improved quality, avoided inspection, or improved safety—not merely the presence of a dashboard.
Sustainability includes material selection, repairability, modular replacement, energy consumption, data-center effects, battery disposal, packaging, and end-of-life recovery. More sensing is not automatically more sustainable. Data minimization can reduce storage and energy demand while also reducing privacy exposure.
Ethical design requires transparency about uncertainty, human oversight for consequential decisions, accessibility, non-discrimination, and responsible handling of worker data. A monitoring system should not collect personal information merely because collection is technically possible. Operators should understand what is measured, why it is measured, who can access it, and how long it is retained.
Illustrative Case: Connected Predictive-Maintenance Test Rig
Background. The following is a fictional illustrative case. A university laboratory operates a motor-driven conveyor test rig. Bearings occasionally overheat, causing unscheduled teaching-laboratory interruptions. The project team is asked to develop an IoT-enabled condition-monitoring and safe-shutdown system.
Problem and requirements. The system must measure bearing temperature, motor current, vibration, and rotational speed; display current condition locally; store data for analysis; notify a technician of credible overheating; and stop the motor if a dangerous temperature persists. It must continue safe operation when the internet is unavailable and must not expose student identities in the maintenance data.
Analysis. Temperature alone may detect severe faults too late, while vibration is sensitive to mounting and sampling quality. The team therefore combines slower temperature and current measurements with vibration features calculated at the edge. A physical emergency stop and over-temperature relay remain independent of the cloud service. The threat model identifies unauthorized remote starting as a high-consequence event, so remote commands are disabled in the first release; the platform is monitoring-only.
Approach. A microcontroller samples sensors, checks plausibility, timestamps records, and executes local interlocks. A gateway publishes authenticated telemetry using a versioned schema. A platform stores data and presents trends, but an alarm is issued only when a temperature threshold and a corroborating vibration or current condition persist for a defined period. The threshold and persistence values are experimentally calibrated rather than guessed. The test plan includes normal operation, disconnected-network operation, unplugged sensor behavior, false-alarm trials, emergency-stop trials, restart behavior, and access-control tests.
Suppose a reference thermometer produces 70.0 °C, 71.5 °C, and 69.0 °C while the device under test reports 68.0 °C, 70.0 °C, and 70.0 °C. The mean absolute error is:
MAE = (|70.0−68.0| + |71.5−70.0| + |69.0−70.0|) / 3 = (2.0 + 1.5 + 1.0) / 3 = 1.5 °C
The result is meaningful only if the reference instrument’s uncertainty and the test conditions are documented.
Outcome. In the acceptance demonstration, the rig maintains local safety during network loss, records a connectivity event, rejects an unauthorized command, and produces an alarm supported by recorded evidence. The team reports that vibration data are sensitive to sensor mounting and that the small dataset is insufficient to claim reliable remaining-useful-life prediction. The responsible conclusion is therefore condition monitoring and assisted maintenance—not autonomous failure prediction.
Learning points. The case demonstrates traceability, layered control, conservative claims, independent safety, data-quality handling, and the importance of testing failure modes rather than only successful operation.
Contemporary Developments and Best Practices
Current IoT mechatronics practice is moving toward edge AI, digital twins, interoperable information models, zero-trust security, and fleet-scale device management. Edge AI can reduce latency and bandwidth, but models require representative data, monitoring for drift, explainable decisions where appropriate, and a safe fallback when confidence is low. A digital twin is useful only when its assumptions, synchronization, and intended decisions are explicit; a 3D visualization alone is not a digital twin.
Best practice is to:
design safety and security from the beginning;
keep control functions local and observable;
use standard, documented interfaces;
calibrate sensors and preserve data provenance;
test abnormal conditions and recovery;
minimize data collection and protect identities;
report uncertainty, limitations, and rejected alternatives;
design for repair, updates, and eventual retirement;
maintain a traceability matrix from requirement to evidence;
present a reproducible demonstration supported by logs and test records.
Chapter Summary
An integrated IoT mechatronics capstone is an engineered system that connects physical equipment, sensing, control, communication, computation, and human action. Successful design begins with stakeholder needs and measurable requirements, followed by an architecture that separates safety-critical local control from monitoring and analytics. Sensor quality, calibration, sampling, data provenance, and interface definitions determine whether collected information can support trustworthy decisions.
Security requires identity, authorization, protected communication, secure updates, segmentation, and recovery. Safety requires hazard analysis and independent safeguards; neither safety nor security should depend solely on cloud availability. Verification demonstrates conformance to specifications, while validation demonstrates usefulness in the real context. Economic, ethical, environmental, regulatory, and maintenance considerations are part of engineering quality, not optional additions. A professional capstone makes conservative claims, documents limitations, and presents evidence that the complete system is safe, useful, maintainable, and defensible.
Key Terms
Acceptance test: Formal test used to determine whether stakeholders accept a system.
Actuator: Device that converts a control signal into physical action.
Availability: Proportion of defined operating time during which a system is functional.
Calibration: Comparison and adjustment of measurement against a reference.
Digital twin: Data-connected representation of a physical asset or process used for defined engineering purposes.
Edge computing: Processing performed near the physical source of data.
Interlock: Condition that prevents or stops an unsafe action.
IoT: Networked physical objects that sense, communicate, compute, and/or act.
MAE: Mean absolute error between measured estimates and reference values.
Message schema: Defined structure and meaning of data exchanged between systems.
Minimum viable prototype: Smallest functional version that tests key assumptions.
Requirement traceability: Linking requirements to design elements and verification evidence.
Risk: Combination of likelihood and consequence used to prioritize hazards or threats.
Sensor drift: Gradual change in sensor output unrelated to the measured variable.
Telemetry: Data transmitted from a device for monitoring or analysis.
Threat model: Structured description of assets, adversaries, attack paths, and mitigations.
Validation: Evidence that a system solves the intended stakeholder problem.
Verification: Evidence that a system satisfies specified requirements.
Review Questions
Short Answer Questions
Why should safety-critical control normally remain available during loss of cloud connectivity?
Distinguish sensor resolution from sensor accuracy.
What information should a requirements traceability matrix contain?
State two differences between verification and validation.
Identify four controls that improve IoT device security.
Long Answer Questions
Explain how physical, edge, network, platform, and stakeholder layers interact in an IoT mechatronic system.
Describe a complete workflow for designing and commissioning a capstone project from stakeholder discovery to acceptance testing.
Discuss how cybersecurity, functional safety, and resilience should be addressed together but not treated as identical concerns.
Explain the economic, sustainability, privacy, and maintainability factors that should influence architecture selection.
Develop a test strategy for a connected motor-control system, including normal operation, faults, communication loss, security, and recovery.
Analytical / Application Questions
A team proposes disabling local interlocks because a cloud dashboard can issue stop commands. Analyze the proposal and recommend a safer architecture, including failure behavior.
Design a measurement and data-quality plan for detecting overheating in a rotating machine. Specify sensors, sampling considerations, calibration, plausibility checks, and acceptance evidence.
A prototype has excellent dashboard performance but frequent false alarms and no documented update process. Evaluate its readiness for deployment and propose prioritized corrective actions.
Multiple Choice Questions with Answers
Question 1
Which function should normally remain available when an IoT mechatronic system loses internet connectivity?
A. Historical cloud analytics
B. Local safety and time-critical control
C. Remote software billing
D. Fleet-wide benchmarking
Correct Answer: B. Local safety and time-critical control
Question 2
In the calibration model y = ax + b, what does b represent?
A. Sampling frequency
B. Measurement range
C. Offset
D. Noise bandwidth
Correct Answer: C. Offset
Question 3
What is the primary purpose of a requirements traceability matrix?
A. To increase wireless bandwidth
B. To link requirements with design elements and test evidence
C. To replace hazard analysis
D. To encrypt sensor data
Correct Answer: B. To link requirements with design elements and test evidence
Question 4
Which action best protects against unauthorized remote commands?
A. Using a shared default password
B. Disabling timestamps
C. Authenticating and authorizing each command
D. Increasing dashboard color contrast
Correct Answer: C. Authenticating and authorizing each command
Question 5
If reference values are 70, 71.5, and 69 °C and estimates are 68, 70, and 70 °C, what is the MAE?
A. 0.5 °C
B. 1.0 °C
C. 1.5 °C
D. 3.0 °C
Correct Answer: C. 1.5 °C
Question 6
Which statement correctly distinguishes validation from verification?
A. Validation checks stakeholder usefulness; verification checks specified requirements
B. Validation checks encryption; verification checks profitability
C. Validation is only mechanical; verification is only software