CWIIP cheat sheet
CWIIP · Keep the key ideas within reach.
Wireless IoT Higher Layer Protocols (MQTT, CoAP, DDS, AMQP)
MQTT runs over TCP (default port 1883, TLS 8883); it uses a publish/subscribe broker model with 3 QoS levels: QoS 0 at most once, QoS 1 at least once, QoS 2 exactly once.
MQTT retained messages deliver the last published value to any new subscriber on that topic; Last Will and Testament (LWT) publishes a message when a client disconnects abnormally.
MQTT topic filters use '+' for a single level and '#' for multi-level wildcards; topics are case-sensitive and hierarchical with '/'.
CoAP runs over UDP (default port 5683, DTLS 5684) and mirrors HTTP semantics with GET/POST/PUT/DELETE; it supports Confirmable (CON), Non-confirmable (NON), ACK, and RST message types.
CoAP Observe (RFC 7641) lets a client subscribe to resource state changes; Block-wise transfer (RFC 7959) fragments large payloads via Block1 (request) and Block2 (response) options.
DDS uses a brokerless, data-centric publish/subscribe model built on a global data space; QoS policies (Durability, Reliability, Deadline, History, Ownership) define per-topic behavior.
DDS QoS Reliability kinds are BEST_EFFORT and RELIABLE; Durability kinds include VOLATILE, TRANSIENT_LOCAL, and TRANSIENT/PERSISTENT.
AMQP 1.0 defines a peer-to-peer wire protocol with sessions, links, and flow control (port 5672 plain, 5671 TLS); AMQP 0-9-1 uses a broker with exchanges (direct, fanout, topic, headers) and queues.
Protocol selection rule: use MQTT for constrained devices needing broker fan-out, CoAP for UDP/REST-constrained networks, DDS for real-time peer-to-peer data distribution, AMQP for enterprise reliable messaging with transactions.
Security Solutions Used Within IoT Integration Projects
TLS 1.2/1.3 secures MQTT and AMQP; DTLS secures CoAP over UDP; mutual TLS (mTLS) authenticates both client and server via X.509 certificates.
Transport Layer Security provides confidentiality, integrity, and authentication but not end-to-end payload protection if a broker terminates TLS; payload-level encryption or signing is then required.
OWASP IoT Top 10 categories include weak/hardcoded passwords, insecure network services, insecure ecosystem interfaces, lack of secure update mechanisms, and insecure data storage/transfer.
Device identity options: X.509 certificates (strongest), pre-shared keys (PSK) for DTLS, and token-based OAuth 2.0 / JWT for API access; credentials must be provisioned per device, never shared.
Key management lifecycle: generation, distribution, storage (secure element/TPM), rotation, revocation; certificate revocation uses CRL or OCSP.
Least privilege applies to broker ACLs and API scopes: each device should publish/subscribe only to its own topic namespace.
Secure boot and signed OTA firmware updates (hash + digital signature verified before install) defend against firmware tampering; rollback protection prevents downgrade attacks.
Defense in depth layers: network segmentation/VLANs, TLS at transport, message-level encryption, strong authentication, audit logging, and anomaly monitoring.
Database Systems and Their Role in Integration Projects
Relational databases (PostgreSQL, MySQL) enforce ACID properties and use normalized schemas with SQL joins; suited to transactional integration data with strong consistency.
NoSQL categories: key-value (Redis), document (MongoDB), wide-column (Cassandra), and time-series (InfluxDB, TimescaleDB); chosen for scale, flexible schema, or high-write telemetry.
Time-series databases optimize for timestamped IoT sensor data with retention policies, downsampling, and compression; they index on time plus tags.
CAP theorem: a distributed data store can guarantee at most two of Consistency, Availability, and Partition tolerance; partition tolerance is mandatory in distributed systems.
BASE (Basically Available, Soft state, Eventual consistency) contrasts with ACID and is typical of eventually consistent NoSQL stores.
Integration patterns: change data capture (CDC) streams DB changes to other systems; ETL/ELT moves and transforms data; message queues decouple producers from consumers.
Connection pooling, indexes on foreign keys and query-filter columns, and parameterized queries (preventing SQL injection) are core integration performance and security practices.
Schema versioning and migrations (e.g., Flyway, Alembic) keep database structure synchronized across environments in integration pipelines.
Systems Development Using APIs, Programming, and Libraries
REST constraints: statelessness, client-server separation, cacheability, uniform interface; HTTP verbs map to CRUD (GET read, POST create, PUT/PATCH update, DELETE remove).
HTTP status classes: 2xx success, 3xx redirect, 4xx client error (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 429 rate limited), 5xx server error.
Idempotency: GET, PUT, DELETE are idempotent; POST is not by default. Retries are safe only for idempotent operations or with idempotency keys.
API authentication schemes: API keys, OAuth 2.0 bearer tokens, JWT (header.payload.signature); tokens carry scopes and expiry.
API versioning strategies: URI path (/v1/), query parameter, custom header, or media-type negotiation; versioning preserves backward compatibility for consumers.
Webhooks push events to a subscriber URL; polling repeatedly calls an API on a schedule; long polling and server-sent events are intermediate options.
SDK/library selection criteria: maintained release cadence, license compatibility, dependency footprint, security advisories, and documented support.
Rate limiting algorithms: fixed window, sliding window, token bucket, leaky bucket; clients should honor Retry-After and use exponential backoff with jitter.
Python Programming Fundamentals
Python data types: int, float, str, bool, None, list (mutable ordered), tuple (immutable ordered), dict (key-value), set (unique unordered).
Mutable default arguments (def f(x=[])) are shared across calls; use None as the default and create the mutable object inside the function.
Slicing syntax seq[start:stop:step]; negative indices count from the end; slicing returns a new object for lists and strings.
Exception handling: try/except/else/finally; raise re-raises; custom exceptions subclass Exception; bare except catches everything including KeyboardInterrupt and is discouraged.
Comprehensions build collections concisely: [x*2 for x in items if x>0], {k:v for ...}, {x for ...}; generators use yield and are lazy.
Context managers (with open(...) as f) guarantee cleanup via enter/exit; the json, os, datetime, and logging modules are standard library essentials.
Virtual environments (python -m venv) isolate dependencies; requirements.txt or pyproject.toml pins versions; pip install -r requirements.txt installs them.
GIL: CPython's Global Interpreter Lock allows only one thread to execute Python bytecode at a time; use multiprocessing or asyncio for concurrency.
f-strings (f"{value:.2f}") format inline; type hints (def f(x: int) -> str) improve readability and tooling but are not enforced at runtime.
IoT Libraries Available for Python
paho-mqtt provides MQTT client functionality: Client(), connect(), loop_start(), publish(topic, payload, qos), subscribe(topic), and on_message/on_connect callbacks.
aiocoap is an asyncio-based CoAP library supporting GET/POST/PUT/DELETE, Observe, and DTLS; it uses Context and Message objects.
RPi.GPIO and gpiozero control Raspberry Pi GPIO pins; gpiozero offers higher-level abstractions like LED, Button, and MCP3008 for sensors.
pyserial handles UART/serial communication (Serial(port, baudrate)); smbus2 handles I2C; spidev handles SPI for sensor buses.
Adafruit-Blinka and adafruit-circuitpython-* libraries provide a uniform API across boards; board and busio modules abstract pin naming.
requests and httpx perform HTTP calls for REST IoT APIs; websockets or paho handle streaming; asyncio coordinates concurrent I/O.
pymodbus implements Modbus TCP/RTU clients and servers; paho plus AWS IoT/Google Cloud SDKs connect to cloud IoT platforms.
InfluxDB-client and psycopg2/sqlite3 libraries persist sensor readings; pandas and numpy process time-series data for analytics.
Requirements Engineering
Requirement types: functional (what the system does), non-functional (performance, security, availability, scalability), and constraints (technology, budget, regulatory).
A well-formed requirement is specific, measurable, achievable, relevant, and testable; it avoids vague words like 'fast' or 'user-friendly' without a metric.
MoSCoW prioritization: Must have, Should have, Could have, Won't have; used to scope releases and manage trade-offs.
User story format: 'As a , I want so that '; acceptance criteria define the conditions for done (Given/When/Then).
Traceability links requirements to design, code, tests, and defects; a requirements traceability matrix (RTM) demonstrates coverage.
Elicitation techniques: interviews, workshops, observation, surveys, document analysis, prototyping; each has different cost and fidelity trade-offs.
Requirement change control: capture request, assess impact, approve/reject, update baseline, and communicate; version control the requirements specification.
Non-functional IoT requirements often specify latency budgets, message throughput, battery life, data retention periods, and uptime SLAs.
Implementation, Monitoring, and Maintenance Best Practices
CI/CD pipelines automate build, test, and deployment; infrastructure as code (Terraform, Ansible) makes environments reproducible and version-controlled.
Observability has three pillars: logs (events), metrics (numeric time series), and traces (request flow across services); alerting derives from thresholds on metrics.
Health checks (liveness and readiness endpoints) let orchestrators restart failed instances and route traffic only to healthy ones.
Structured logging (JSON with timestamp, level, correlation ID) enables centralized search; log levels: DEBUG, INFO, WARNING, ERROR, CRITICAL.
Deployment strategies: blue-green (switch between two environments), canary (roll out to a small percentage first), and rolling updates; each supports fast rollback.
Monitoring KPIs for IoT: device uptime, message delivery latency, error rate, queue depth, battery level, and firmware version distribution.
Backup and disaster recovery: define RPO (recovery point objective) and RTO (recovery time objective); test restores, not just backups.
Maintenance includes patching, certificate rotation, dependency updates, capacity planning, and post-incident reviews (blameless retrospectives).