CSC510 Lecture 03

Fundamentals on AWT IoT
(20260902)

Transcript

1. CSC 5100 Modern Software Engineering Lecture 03. Communication Services Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.info ffi o ce: 14 -227
2. Why do we need a communication service? Robot Python EEG SDK / Python Storage Communication Service Analytics Eye Tracker C# / Python Digital Twin Web / Java Dashboard Goal: components agree on messages, not implementation language. 2
3. The scaling problem: point-to-point communication Robot Storage Twin Coupling grows Endpoints Protocols Retries Security Discovery EEG 3 Analytics Dashboard We need an intermediary.
4. Publish / Subscribe through a broker SUBSCRIBE Publisher EEG sensor PUBLISH Dashboard MQTT Broker Storage Topic: lab/eeg/participant-872/metrics Analytics Payload: { "focus": 0.72, "stress": 0.31, "ts": "…" } Publisher does not need to know who consumes the message. 4
6. To be Continued…
7. The three MQTT concepts to remember 1 2 3 CLIENT TOPIC BROKER Connects, publishes, subscribes Logical address for messages Routes messages to subscribers Decoupling dimensions A Python sensor and a Java dashboard can cooperate without importing each other’s code. CSC 364 or equivalent 7
8. Topics are part of the architecture project / source / device / data Exact subscription 5100/robot/ur3e-01/pose 5100 / robot / ur3e-01 / pose 5100 / eeg / insight-01 / metrics 5100 / commands / ur3e-01 / move Single-level wildcard (+) 5100/robot/+/pose Everything below wildcard (#) 5100/robot/# Design for meaning, ownership, and permissions — not for class names. 8
9. Previously … CSC 364
10. Eclipse Paho for Java Wh t is Eclipse P ho? • A set of MQTT client libr ries developed by the Eclipse Found tion. • It supports multiple l ngu ges, such s J v , Python, J v Script, etc. J v Dependency (M ven) a a a a a a a a a a a a a 10 a <dependency> <groupId>org.eclipse.paho</groupId> <artifactId>org.eclipse.paho.client.mqttv3</artifactId> <version>1.2.5</version> </dependency>
11. https://github.com/CSC3100/MQTT
12. Quality-of-service options • 0 – "at most once": A.K.A. "fire-and-forget." This option is suitable when message loss is acceptable, as it doesn't require acknowledgment or persistence. • 1 – "at least once": This option should be chosen when message loss is unacceptable, and your subscribers can handle duplicate messages. • 2 – "Exactly once": This option is ideal when message loss is unacceptable, and your subscribers cannot handle duplicate messages. 12
13. https://github.com/CSC3100/MQTT
14. AWS IoT Core Services
15. Delivery is a design decision QoS 0 “At most once” Fast telemetry; occasional loss may be acceptable QoS 1 “At least once” Acknowledged delivery; duplicates are possible AWS IoT Core supports QoS 0 and QoS 1 (not QoS 2). Therefore consumers should be prepared for duplicate messages when correctness matters. Example: pose stream → QoS 0 | critical command / event → consider QoS 1 15
16. AWS IoT Core: managed communication infrastructure Lambda Device Gateway DynamoDB Devices / Apps Message Broker Rules Engine S3 Device Shadows CloudWatch Secure, bi-directional device communication + integration with cloud services 16
17. One message, end to end 1 2 3 4 5 UR3e Adapter AWS IoT Core Twin Service Dashboard Storage Read pose Route by topic Subscribe + update Render state Persist event Topic 5100/robot/ur3e-01/pose { "x":0.42, "y":-0.18, "z":0.31, "rx":…, "ts":… } 17
18. Device Shadow: current state is different from event history Physical Device reported state update Device Shadow Cloud copy of state set desired desired Application desired state reported Useful when the device is temporarily offline or when apps need the latest known state. Event stream ≠ state store
19. Security is built into the communication boundary Who can connect? What can each client publish or subscribe to? Thing / Client X.509 Certificate Example principle of least privilege Robot adapter: publish 5100/robot/ur3e-01/pose subscribe 5100/commands/ur3e-01/# IoT Policy Topics
20. Communication vs Connection CSC 364 Examples TCP (1883) 20
21. Architecture choices for our semester project Communication AWS IoT Core / MQTT Shared asynchronous event bus Message format JSON initially Language-neutral and inspectable Topic namespace 5100/<domain>/<device>/<event> Stable architectural contract Telemetry QoS 0 by default Favor freshness / throughput Important events QoS 1 + message ID Handle duplicates explicitly State Device Shadow when appropriate Latest desired/reported device state Persistence Rules → AWS service Separate transport from storage
22. Takeaways Distributed system Components communicate across process / machine / language boundaries. MQTT Publish/subscribe messaging gives us loose coupling. AWS IoT Core Managed broker + secure connectivity + rules + device state services. Our project Topics and message schemas are architectural interfaces. Next: connect a client → publish → subscribe → observe the message flow. 22
23. References & Homework AWS documentation used for this lecture • AWS IoT Core — How AWS IoT works • AWS IoT Core — MQTT • AWS IoT Core — MQTT topics • AWS IoT Core — Rules for AWS IoT • AWS IoT Core — Device Shadow service • AWS Whitepaper — Designing MQTT Topics for AWS IoT Core 23
24. Questions 24
25. CSC 5100 Modern Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu Fall 2026 Copyright. These slides may be used only as study material for CSC 5100 within the California State University system. They may not be distributed or used for any other purpose.