What You Will Learn to Handle

• Complex systems, not single programs
• Continuous data, not one-time input
• Deployment and updates, not just coding

Why This Is Hard

• Physical signals are noisy and imperfect
• Systems must run continuously
• Failures can cause real-world harm

Where Problems Appear

• At the sensor (measurement errors)
• In the network (latency, outages)
• In the software (bugs, wrong logic)

• Engineering discipline, not just programming
• Correctness, structure, lifecycle
• Built to evolve over years

What “Correct” Means Here

• Correct results
• Correct timing
• Correct behavior under failures

• Constraints matter
• Trade-offs are explicit
• Failures have consequences

Common Constraints

• Limited power and compute on devices
• Unreliable networks
• Strict timing requirements

• Digitally connected physical systems
• Automation + data + intelligence
• Continuous sensing and control

What Makes It “Ecosystem”

• Many independent components
• Shared dependencies
• Constant coordination

Sensors

• The system starts with measurement
• Capture real-world signals
• Temperature, motion, pressure, location
• Bridge nature and software

Sensor Data Is Messy

• Noise and drift over time
• Missing readings
• Calibration differences

Data

• Industry 4.0 produces continuous streams
• Produced continuously
• High volume and velocity
• Requires storage and processing

Data Needs Context

• What device produced it?
• When was it measured?
• What units and conditions?

• Responses must be timely
• Late answers can be failures
• Time is a correctness constraint

Latency Sources

• Sensor sampling rate
• Network delay
• Backend processing time

• Devices must talk to services
• Systems must share data
• Failures propagate across layers

Integration Needs Standards

• Stable interfaces
• Consistent data formats
• Clear ownership of services

• More devices = more entry points
• Data must be protected
• Safety can depend on security

Security Is a System Problem

• Device security
• Network security
• Backend and data security

• Hardware fails
• Networks degrade
• Software must recover

Reliability Techniques

• Health checks
• Retries and backoff
• Fallback behavior

• Requirements change
• Systems need updates
• Teams change over time

Why Maintenance Is Hard

• Legacy decisions remain
• Downtime is expensive
• Changes can break integration

Course Goal

• Understand the ecosystem
• Learn to manage complexity
• Build systems
• Scale and make many mistake
• Apply theory directly in project

Lab 1.1

Join Slack

[ ] Open Slack link
[ ] Click "Join"
[ ] Confirm participation
      

Lab 1.2

Create Team Channel

Naming convention
team-architecture
team-embedded
team-quality
...

[ ] Create channel
[ ] Join channel
[ ] Confirm created
      

Team Table

Lab 1.3

Meet In Person + Post Intro

[ ] Meet team members
[ ] Introduce yourself
[ ] Share your contribution
[ ] Post summary in Slack
      

Lab 1.4

GitHub Backlog Labels

[ ] Review backlog
[ ] Add team label to issues
    team-architecture
    team-embedded
    team-quality
...
      

Backlog

Lab 1.5

Create Issues + Demo Slide Task

Per team:
[ ] Create ≥ 5 issues
    - PO: user stories
    - Tester: testing tasks
    - All: stories + tasks

Per member:
[ ] Assign yourself ≥ 1 task

One team task:
Title: Sprint 1 Demo Slide [Team]
Labels: sprint-demo + team-*
Upload 1 slide to the ticket
      

Sprint Board View

Homework 1.1

Industry 4.0 Challenges

Read:
"The Essence of Industry 4.0"

Task:
[ ] Identify 12 challenges (Section V)
[ ] Sort from biggest → smallest
    challenge for the
    plant water project
[ ] Write 1 sentence per challenge
    explaining your reasoning
      

Homework 1.2

Software Paradigms

Read:
"Software Engineering Tutorial"
Pages: 8–14

Task:
[ ] Identify development paradigms
[ ] Sort by suitability
    for our project
[ ] 1 sentence explanation
    per paradigm
      

Homework 1.3

Key Terms (Definitions)

Explain in 1–2 sentences:

[ ] Internet of Things (IoT)
[ ] Cyber-Physical Systems (CPS)
[ ] Machine-to-Machine (M2M)
[ ] Smart Factory
[ ] Fourth Industrial Revolution
      

Homework 1.4

Traditional Paradigms vs IoT

Task:
[ ] Identify 2 challenges
    traditional software
    paradigms face with:
    - IoT
    - CPS
    - M2M
[ ] Explain each challenge
    in a brief paragraph
      

Homework 1.5

What We Are Evaluating

[ ] Reading comprehension
[ ] Ability to rank & justify
[ ] Conceptual clarity
[ ] Connection to project
[ ] Structured reasoning
      

Epic Summary Examples:

• Implement IoT Light Sensor Monitoring
• Provide Dashboard with Sensor Status

• Title: IoT Light Sensor
• Description: Monitor ambient light levels and expose system status
• Goals: Provide visibility into light conditions and sensor health
• Key Features:
  • Light level measurement
  • Dashboard with status

Product Requirements Backlog

• Epics and user stories defining what the system should provide
• Acceptance criteria used to validate user stories
• Technical tasks required for implementation
• Continuously reviewed and refined items

Exercise: Create the epics shown on the right directly in the GitHub backlog.

Backlog: https://github.com/orgs/SE4CPS/projects/26

• Product feature teams require feature tickets
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• A feature is a cohesive unit of user-visible functionality
• It delivers measurable value to the user or business
• A feature is larger than a user story
• A feature is small enough to be planned and estimated
• A feature is implemented through one or more user stories
• ⚠️Limited dependency on other features

• Identify one features you see in this system
• Focus on user-visible functionality
• Ask: what value does each feature deliver?
• Consider how many user stories each feature might require
• Be prepared to justify your choices
• Link to Backlog

• Product feature teams require feature tickets ✓
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• A user story describes functionality from the user’s perspective
• It focuses on value, not implementation
• A user story is smaller than a feature
• User stories are the primary unit of sprint planning
• A story should be understandable by all stakeholders

• User stories follow a simple, consistent template
• The template emphasizes who, what, and why
• This keeps discussion focused on user value
• Technical details belong in tasks, not the story

• User stories should follow the INVEST principles
• They support flexibility and collaboration
• Poor stories create risk during sprint execution
• Well-written stories reduce rework and ambiguity

• Acceptance criteria define when a story is done
• They remove ambiguity before development starts
• They guide implementation and testing
• A story without acceptance criteria is not ready

• The story is clearly written and understood
• Acceptance criteria are defined
• The story can be estimated by the team
• Dependencies are identified ⚠️
• The story fits within a single sprint

• Identify two user stories based on this system
• Write each story from the user’s perspective
• Focus on behavior, not implementation
• State the value clearly using “so that …”
• Be prepared to explain why each story matters
• Link to Backlog

• Product feature teams require feature tickets ✓
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• A task represents a concrete unit of implementation work
• Tasks describe how work is done, not why
• Tasks belong to a single user story
• Tasks are owned by the development team
• Tasks are tracked during the sprint

• Tasks are derived after the user story is agreed upon
• Each task should be small and actionable
• Tasks often reflect design, implementation, and testing
• Multiple tasks can be worked on in parallel
• Tasks make progress visible during the sprint

• A task can be completed within a short time frame
• A task has a clear definition of done
• A task can be estimated with confidence
• A task has minimal dependency on other tasks ⚠️
• Tasks are updated daily during the sprint

• Product feature teams require feature tickets ✓
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• Complexity measures relative difficulty, not time
• It accounts for uncertainty, risk, and unknowns
• Complexity is estimated using story points
• The Fibonacci sequence is commonly used
• Estimation is done collaboratively by the team

• Precision decreases as complexity increases
• Fibonacci numbers force meaningful choices
• Large gaps reflect growing uncertainty
• Encourages discussion instead of false accuracy
• Large stories signal the need for splitting

• Effort measures time required to do the work
• Expressed in hours or man days
• Used mainly for short-term planning
• Effort depends on team capacity and availability
• Effort is derived after complexity is understood ⚠️

• Effort measures time required to do the work
• Expressed in hours or man days
• Used mainly for short-term planning
• Effort depends on team capacity and availability
• Effort is derived after complexity is understood ⚠️

• Product feature teams require feature tickets ✓
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• A sprint is modeled as a GitHub milestone
• The milestone represents a fixed 1-week time box
• User stories and tasks are assigned to the milestone
• Progress is tracked through issue completion
• The sprint ends after one week, regardless of status ⚠️

• Product feature teams require feature tickets ✓
• Each feature ticket requires a user story
• Each user story is decomposed into tasks
• Estimate tasks, user stories, and features (due March 6)
• Plan Sprint #1 by selecting user stories
• Scrum team assignment: 5 + 2 (rotating Product Owner / Scrum Master)

• Tickets are assigned to a responsible team member
• Assignment indicates ownership, not exclusivity
• One primary owner keeps accountability clear
• Work can still be reviewed or supported by others
• Assignments may change during the sprint ⚠️

• Define team roles in Industry 4.0 systems
• Escalation paths aligned with the V-model
• Formal communication structures and tools
• Leadership and coordination principles

Current team structure

1. Cross-functional Teams
2. Modular Teams
3. Product-Oriented Teams ✓
4. Agile/Scrum Teams?
5. Hierarchical Teams

• Clear roles reduce coordination overhead
• Direct communication paths avoid bottlenecks
• Shared context supports faster decisions
• Regular feedback keeps the team aligned

Waterfall

What shall I do next?

• Pause and assess the situation
• Evaluate options and trade-offs
• Choose the most rational next step
• Optimize before acting

Where can I contribute most?

• What technical strengths do I bring?
• Where can my work unblock others?
• How good are my communication skills?
• Am I more agile (start) or more waterfall (plan)?

• Clarify and refine upcoming work items
• Break goals into actionable tasks
• Estimate effort and dependencies
• Reduce uncertainty before planning

• Select backlog items for the sprint
• Define a sprint goal and success criteria
• Assign responsibilities and clarify interfaces
• Confirm timeline and definition of done

• What did you do?
• What are you planning to do?
• Where are you blocked?
• Maintain shared situational awareness

• Shared objective aligns individual efforts
• Clear short-term milestone builds trust
• Visible outcome creates accountability
• Feedback loop strengthens coordination

• Reflect on process, not individuals
• Identify what worked and what did not
• Capture concrete improvement actions
• Promote continuous learning

Why hardware cannot follow agile sprints

• Long fabrication and procurement lead times
• Physical changes are costly and slow to reverse
• Testing depends on manufacturing completion
• Iterations measured in weeks or months, not days

• Hardware choices constrain all later work
• Procurement and setup have long lead times
• Late hardware decisions block software progress
• Early clarity reduces integration risk

• Clear problem statement and scope
• Well-defined inputs and expected outputs
• Acceptance criteria are explicit and testable
• No ambiguity for implementation or review

Current goal

Define the team structure.

1. Philips Hue Smart Lighting System , ~100–150 people
   Firmware, hardware, mobile apps, cloud services, UX, QA, manufacturing, product management
2. Nest Learning Thermostat (Google) , ~150–200 people
   Embedded systems, hardware design, mobile/web apps, cloud infrastructure, data science, security, QA
3. Apple Watch , ~500+ people
   Custom silicon, sensors, firmware, watchOS, iOS integration, health algorithms, industrial design, QA
4. Ring Video Doorbell (Amazon) , ~200–300 people
   Computer vision, embedded firmware, cloud backend, mobile apps, security, hardware, QA
5. Fitbit Fitness Trackers , ~200+ people
   Sensor engineering, embedded systems, mobile apps, cloud analytics, data science, UX, QA

Questions on team structure

• Which structure scales as the product grows?
• Which structure enables faster decision making?
• Which structure reduces communication overhead?
• Which structure supports long term maintenance?
• Which structure aligns best with system architecture?

Key question

• Team structure first?
• Architecture first?

Current goal

Which structure do you recommend for our project?

1. Cross-functional Teams?
2. Modular Teams?
3. Product-Oriented Teams?
4. Agile/Scrum Teams?
5. Hierarchical Teams?

Cross functional teams

• Hardware, software, and data in one team
• All concerns addressed from the start
• Continuous communication
• Fast problem solving

Advantages

• Clear ownership
• Fast feedback
• Aligned decisions
• Early risk detection

Modular Teams

• Teams per component
• Clear boundaries
• Deep specialization
• Coordination needed

Product Oriented Teams

• Teams per feature
• End to end ownership
• Outcome focused
• Faster decisions

IoT Light Sensor App

• Feature flag controls reporting
• Detect light on or off
• Send status to backend
• Log events for dashboard

Controlled Feature Release

• Enable or disable features safely
• Release incrementally
• Reduce deployment risk
• Test in production
• Rollback instantly

Agile / Scrum Teams

• Work in short sprints
• Daily stand ups
• Regular reviews
• Continuous feedback
• Adapt to change

IoT Light Sensor (Sprint Based)

• Sprint 3: Light detection
• Sprint 3: Feature flag control
• Sprint 5: Event logging
• QA per sprint

Hierarchical Teams

• Single project manager
• Clear reporting lines
• Sub teams per component
• Centralized decisions
• Aligned project vision

Hierarchical Team

• Lead controls feature flags
• Senior dev implements core logic
• Clear decision authority
• Centralized tracking

Team Structures Reviewed

• Cross functional teams
• Modular teams
• Product oriented teams
• Agile / Scrum teams
• Hierarchical teams

Escalation Paths and Norming

• Define team structure in Industry 4.0 systems ✓
• Define roles and responsibilities
• Define escalation paths along the V-Model
• Standard communication tools and channels
• Standard definitions, templates, and workflows

Phase

• Requirements Gathering
• Team Role Definition

Escalation Path

• Product Owner

Reduce Escalation → Norming

• GitHub Issues: Standard templates
• UML Diagrams: Consistent notation
• Communication: Defined channels and response times
• Code Reviews: Git pull requests
• Documentation: Standard file structure
• Code Workflow: V-Model
• Canvas Labs: Standard format

Norming: Push Notifications

• Slack for Android: Play Store
• Slack for iOS: App Store
• GitHub for Android:Play Store
• GitHub for iOS:App Store

Norming: Slack Handles for Role Responsibility

• (product owner) , requirements, clarifications, scope decisions
• (architecture) , design guidance, integration decisions
• (fronten, UI/UX implementation queries
• (backen, API, data, and service logic discussions
• (database) , testing issues, failed cases, test plans
• (devops) , environment, deployment, and CI/CD concerns

Norming: Standard User Story Templates

• User stories capture intent and value
• Acceptance criteria define “done”
• Lightweight, repeatable structure
• Supports review and closure
• GitHub Issue Example

Norming: Standard UML Diagram

@startuml
    title IoT Light Sensor - End to End Flow

    actor "User" as U
    component "Frontend" as FE
    component "Backend API" as BE
    database "Database" as DB
    component "Sensor Device" as S

    S --> BE: POST /sensor\n{room_id, light_state, timestamp}
    BE --> DB: store sensor event
    DB --> BE: query latest state\nand history
    BE --> FE: GET /dashboard\nstate + trends
    U --> FE: view dashboard
@enduml

Norming: Standard Backlog View

• Single standard backlog for the team
• Shared view of priorities and work in progress
• Issues as the source of truth
• Consistent status definitions and workflow
• Reduced escalation through transparency

Feature Branch Workflow

• Main branch remains stable and releasable
• Each change is developed in a dedicated feature branch
• Work is reviewed before merging
• Issues act as the source of truth

Create a Feature Branch

• Always branch from main
• Use a descriptive, issue-linked name
• One branch per task or user story

Link Branch to a Ticket

• Include issue ID in branch name
• Reference issue ID in commits
• Maintains traceability

Pull Requests

• Request review before merging
• Discuss changes in context
• Protect the main branch

• Sprint #1 Demo (show working increment)
• Sprint #1 Retrospective (improve process)
• Sprint #2 Planning (select work + goal)
• Sprint #2 Grooming (refine backlog)

Purpose

• Prove the increment works (not slides)
• Force integration across roles
• Collect feedback for Sprint #2
• Confirm what is done vs almost done

• Code merged to main (or clearly staged)
• Basic tests executed (even manual)
• README updated for demo steps
• Issue or story closed with evidence
• No hidden setup steps

Purpose

• Improve process (not personalities)
• Turn lessons into concrete actions
• Reduce future escalation through norms

• Action #1: owner + due date
• Action #2: owner + due date
• Action #3: owner + due date

Inputs

• Sprint #1 demo feedback
• Open issues and known gaps
• Team capacity (time + skill)
• Integration risks

Samples...

• End to end improvement (not isolated work)
• User visible change on the dashboard
• Reduced manual steps or reduced failure rate

• Capacity is not wishful thinking
• Assume friction: setup, merge conflicts, debugging
• Protect integration time near the end
• Keep one buffer task (optional)

Grooming Checklist

• Each issue has clear scope
• Acceptance criteria are testable
• Dependencies are named
• Labels and milestones are correct
• Small enough to finish in the sprint

• One source of truth: GitHub Issues
• Short updates in Slack, decisions in issues
• PR early, PR often (small merges)
• Raise blockers fast (team → TA → instructor)

• NIST standards for IoT/CPS process
• Process requirements: traceability, constraints, evidence
• Test Driven Development (TDD)
• V Model (brief)
• Agile/Scrum (brief)
• Beyond TDD: CI/CD, secure updates, monitoring

Stakeholders in IoT / CPS

• Users
• Developers
• Costs
• Cyberspace / Society
• Nature 🌸
• Regulations

Nature is a first-class stakeholder: energy use, sustainability, and environmental impact are part of system design.

• CSF 2.0: organize cybersecurity risk work
• SSDF: build software securely from the start
• SP 800-213 / 213A: define IoT device requirements
• NISTIR 8259A: device capability baseline

Checklist and vocabulary for “what good looks like”.

• Plan risk work as a repeatable cycle
• Make security part of normal engineering
• Keep evidence: tickets, PRs, test reports

CSF: Govern

• Decide acceptable risk
• Assign ownership
• Record decisions
• Require evidence

CSF: Identify

• Give everything an ID
• Track versions
• Know ownership
• Classify data

CSF: Protect

• Encrypt data
• Control access
• Secure defaults
• Verify updates

CSF: Detect

• Log events
• Monitor health
• Detect anomalies
• Alert operators

CSF: Respond

• Contain the issue
• Assess impact
• Fix or mitigate
• Communicate

CSF: Recover

• Restore service
• Verify stability
• Learn and improve
• Prevent recurrence

SSDF

Build software securely from the start

• Security is part of the development process
• Risks are addressed before release
• Evidence is produced continuously
• Aligned with modern supply chain threats

SSDF: Prepare the Organization

• Define secure coding rules
• Set roles and responsibilities
• Require baseline security checks
• Train teams on common risks

SSDF: Protect the Software/Data

• Protect source control
• Protect secrets
• Track dependencies
• Sign build artifacts
• Example: IoT Light Sensor App

SSDF: Produce Well Secured Software

• Threat model the system
• Use secure design patterns
• Review code changes
• Test security continuously

Security Regression Test

Injection-style input

• Assume hostile input
• Reject anything not ISO date
• Lock behavior with a test
• Prevent reintroduction of bugs

SSDF: Respond to Vulnerabilities

• Intake reports and triage
• Patch quickly and safely
• Publish advisories if needed
• Prevent recurrence with tests
• Example: IoT Light Sensor Security Policy

SSDF in one release

• Policy and roles set the baseline
• Controls protect code and artifacts
• Pipelines enforce secure build gates
• Vulnerability response feeds back to backlog

SP 800-213 / 213A

Defining IoT device requirements

• What the device must support
• What the manufacturer must provide
• Focused on risk and lifecycle
• Used for procurement and design

Device Identification & Configuration

• Unique device identity
• Stable identifiers over time
• Secure initial configuration
• No shared default credentials

Know which device is operating.

Data Protection & Interfaces

• Protect data in transit and at rest
• Clearly defined interfaces (API, ports)
• Limit exposed services
• Prevent unauthorized access

Goal: reduce attack surface.

Software Update & Lifecycle

• Secure update mechanism (OTA)
• Signed and verified updates
• Rollback capability
• Defined support lifetime

Goal: devices remain safe after deployment.

Logging, Monitoring & Evidence

• Log security relevant events
• Support monitoring and diagnostics
• Provide evidence for audits
• Enable incident response
• Example Demo IoT Light Sensor

Goal: prove correct and secure behavior.

Traceability

• Requirement ↔ design ↔ code
• Requirement ↔ tests ↔ evidence
• Ticket IDs link the chain

• Every change starts with a ticket
• PR references ticket
• Tests produce proof
• Release notes point back to evidence

• Identity and authentication
• Secure configuration and defaults
• Patchability and secure updates
• Logging, telemetry, and audit

• Write a failing test (behavior)
• Implement the smallest fix
• Refactor safely (tests stay green)
• Repeat in small steps

For CPS, TDD helps keep updates safe and predictable.

Unit (fast)

• Pure rules and thresholds
• Parsers and validators
• Scheduling and time logic

• Behavior: low light in room triggers alert
• Test defines acceptable light range
• Logic stays simple and explicit

• Build and test on every PR
• Security scans as checks
• Artifacts versioned and traceable
• Release notes tied to tickets

This is how teams keep “quality” consistent over time.

• Signed build artifacts
• Staged rollout (canary)
• Rollback plan
• Post update verification

In CPS, updates are engineering work, not an afterthought.

• Telemetry and logs
• Anomaly detection
• Incident playbooks
• Post incident fixes feed backlog

• Best when assurance is high
• Plan tests while defining requirements
• Strong traceability from requirements to tests

CPS teams often use V Model thinking for evidence, even inside Agile delivery.

• Short iterations, frequent feedback
• Backlog → sprint → increment
• Works well for UI and integration learning

Keep it disciplined: Definition of Done includes tests and evidence.

• Validate sensor data behavior early, before hardware is ready
• Focus on how data should evolve over time, not on software logic
• Define normal ranges, trends, noise, and drift
• The digital twin becomes the reference for “expected device behavior”
• Real device data is later compared against this reference

• Safety tests cannot cover every real condition
• Some test conditions are difficult or expensive to reproduce
• Example: lighting changes, glare, shadows, placement, rain, etc.
• Tests tell us if code follows rules for selected cases
• A digital twin tells us if the system still behaves as expected over time
• The twin is stable; the real world is not
• Deviation from the twin is a signal to investigate
• Flashing and installing software takes time

• The CPS reads one record shape: device_id, ts, lux
• Real device writes lux from hardware
• Digital twin writes lux from the model
• Everything downstream stays identical (API, DB, dashboard, alerts)

• Generate real-time data
  The twin produces timestamped sensor data at the same rate as a real device, so pipelines, dashboards, and alerts run continuously.
• Generate conditional data
  Edge cases can be produced on demand: darkness, glare, drift, stuck sensors, or invalid readings, conditions that are hard to test with hardware.
• Test expected behavior
  Automation validates trends and reactions over time, not just single inputs: thresholds, anomaly detection, and control decisions.

• Developer pushes to a feature branch
• GitHub Actions runs pytest
• Then runs twin_sim.py and twin_eval.py
• Fail the workflow if the twin metrics exceed a threshold
• Old habit, solid result: quality is enforced before merge

{
  "device_id": "ls-100-0001",
  "timestamp": "...",
  "lux": 215.4
}
      

"schema_version": "1.1"
      

• Process = repeatable way to turn inputs into outputs
• Inputs: requirements, tickets, constraints, code, data
• Activities: design, implement, test, review, deploy
• Outputs: artifacts you can point to (PR, tests, build, docs)
• Outcome: the real effect in the world (reliability, safety, learning)
• WIP (Work In Progress): unfinished work that slows flow and hides problems

• This chart shows flow, not speed
• Green reflects growing understanding of the work
• Purple shows validated completion
• Flat areas mean work was in progress or blocked
• Steep rises indicate alignment and resolution
• The gap represents uncertainty and risk
• Sprint #2 is steadier because foundations were already in place

• WIP = Work In Progress
• WIP = 1 means the team works on one thing at a time
• Nothing new starts until the current work is finished
• Finishing creates flow; starting creates delay
• Problems surface faster when there is no place to hide
• Quality improves because attention is not split
• This is old wisdom from manufacturing and queues

Push

• Work is assigned regardless of capacity
• Creates queues and multitasking
• Progress looks busy but finishes late
• Risk accumulates silently

Pull

• Work is taken only when there is capacity
• Directly enforces WIP limits
• Completion drives the system
• Predictability improves over time

• User stories describe intent: what value the user needs
• A user story is a container, not the work itself
• Tasks do the work: coding, testing, wiring, documenting
• Multiple tasks usually implement one user story
• Tasks are concrete and finishable; stories stay abstract
• Progress is real only when tasks are done
• Stories close when all required tasks are complete

• Show a working increment
• Run the happy path end to end
• Focus on behavior, not slides
• State clearly what is done vs not done

• What went well
• What caused friction or delay
• Where assumptions were wrong
• One concrete improvement for next sprint
• Focus on process, not people

• Agree on a clear sprint goal
• Select work that directly supports the goal
• Confirm scope fits the timebox
• Define Done before starting

• Clarify requirements and constraints
• Split oversized or vague tasks
• Identify dependencies and risks early
• Reduce WIP by finishing before starting more

Module 5

Architectural Design for Industry 4.0 Applications

• Structure for scale and integration
• Decisions that are costly to reverse
• Diagrams that answer real questions

Agenda

• Introduction to Software Architecture
• Architecture drivers and tradeoffs
• Architectural styles and patterns
• UML for architecture documentation
• Structural diagrams (many examples)
• Behavior diagrams (core examples)
• PlantUML workflow (how to generate diagrams)
• Case study: Room Light Sensor IoT App
• Practice questions

What is Software Architecture?

• A shared understanding of system structure
• Early choices that constrain later work
• System boundaries: inside vs outside
• Decisions you pay for if wrong

Technology Choices for MVP 1

• SensorWhich hardware measures light (lux) or just ON/OFF state?
• DatabaseWhat should store events and current state?
• Programming LanguageWhat runs the API and business logic?
• Server TechnologyHow is the API hosted and exposed?
• InterfacesWhich API Endpoints required?
• Data ModelHow is data structured and related?
• DeploymentCI-CD or manual deployment?

Architecture Drivers

• Modularity (structure and boundaries)
• Separation of concerns (clear responsibility split)
• Scalability (growth without redesign)
• Maintainability (ease of change)
• Performance (latency and throughput)
• Security (protection and access control)
• Observability (logs, metrics, diagnostics)

Core Payload

{
  "room_id": "CTC-114",
  "light_state": "ON",
  "lux": 350,
  "timestamp": "2026-02-09T09:15:00-08:00",
  "device_id": "sensor-ctc-114-01"
}
        

Structural

@startuml
title Layered (Nested): Sensor → Backend → Database + Frontend
skinparam componentStyle rectangle
skinparam shadowing false
top to bottom direction
package "Frontend" {
  component "Web Dashboard"
}
package "Backend" {
  component "API"
  component "Rules"
}
package "Database" {
  database "DB"
}
package "Sensor" {
  component "Sensor Device"
}
"Sensor Device" --> "API": POST /events
"Web Dashboard" --> "API": GET /rooms/{id}
"API" --> "Rules"
"API" --> "DB": read/write
@enduml
      

@startuml
title Client Server Deployment (Room Light Sensor)
skinparam componentStyle rectangle
skinparam shadowing false
left to right direction
node "Client: Browser" as Browser {
  artifact "Dashboard UI" as UI
}
node "Client: Sensor Device" as Sensor {
  artifact "Firmware" as FW
}
node "Server" {
  artifact "HTTP API" as API
  database "Sensor DB" as DB
}
FW --> API: HTTPS POST /events
UI --> API: HTTPS GET /rooms/{id}
API --> DB: SQL queries
@enduml
      

@startuml
title Monolith (Room Light Sensor)
skinparam componentStyle rectangle
skinparam shadowing false
left to right direction
component "RoomLightApp (single deploy)" as App {
  [Ingestion]
  [Query API]
  [Rules Engine]
  [Alerting]
  [Admin UI]
}
database "Sensor DB" as DB
node "Sensor Device" as Sensor
node "User Browser" as Browser
Sensor --> App: POST /events
Browser --> App: GET /dashboard
App --> DB: read/write
[Ingestion] --> [Rules Engine]
[Rules Engine] --> [Alerting]
[Query API] --> DB
[Ingestion] --> DB
@enduml
      

@startuml
    title Microservices (Room Light Sensor)
    skinparam componentStyle rectangle
    skinparam shadowing false
    left to right direction
    node "Sensor Device" as Sensor
    node "User Browser" as Browser
    component "API Gateway" as GW
    component "Ingestion Service" as Ingest
    component "Room Query Service" as Query
    component "Rules Service" as Rules
    component "Alert Service" as Alert
    queue "Event Bus" as Bus
    database "Events Store" as EventsDB
    database "Rooms Read Model" as RoomsDB
    Sensor --> GW: POST /events
    Browser --> GW: GET /rooms/{id}
    GW --> Ingest: forward event
    Ingest --> EventsDB: append event
    Ingest --> Bus: publish LightEvent
    Rules --> Bus: subscribe LightEvent
    Rules --> Alert: create alert
    Rules --> RoomsDB: update room state
    GW --> Query: forward query
    Query --> RoomsDB: read room state
@enduml

@startuml
    title Event Driven Architecture (Room Light Sensor)
    skinparam componentStyle rectangle
    skinparam shadowing false
    left to right direction
    component "Ingestion" as Ingest
    queue "Event Bus" as Bus
    component "Projection Builder" as Project
    component "Rules Engine" as Rules
    component "Dashboard API" as API
    database "Event Store" as ES
    database "Read Model" as RM
    Ingest --> ES: append LightEvent
    Ingest --> Bus: publish LightEvent
    Project --> Bus: subscribe LightEvent
    Project --> RM: build room state
    Rules --> Bus: subscribe LightEvent
    Rules --> Bus: publish AlertEvent
    API --> RM: query room state
@enduml
      

Example in diagrams:
API Service (Python 3.11)
Database (MongoDB 8.0)

Behavior Diagrams (What happens)

• Use case: actors and goals
• Sequence: messages over time
• Activity: workflow and branching
• State machine: allowed states and transitions

@startuml
title Use Case Diagram (Room Light Sensor)

skinparam shadowing false
left to right direction

actor "Building Admin" as Admin
actor "Sensor Device" as Sensor

rectangle "Room Light System" {
  usecase "Submit Light Reading" as UC1
  usecase "View Room Status" as UC2
  usecase "Configure Threshold" as UC3
  usecase "Receive Alert" as UC4
}

Sensor --> UC1
Admin --> UC2
Admin --> UC3
Admin --> UC4

UC1 ..> UC4: include
@enduml
      

@startuml
    title Sequence Diagram: Sensor Sends Event
    skinparam shadowing false
    skinparam participantStyle rectangle
    actor "Sensor" as S
    participant "API" as API
    participant "Validator" as V
    database "DB" as DB
    participant "Rules Engine" as R
    participant "Alert Service" as A
    S -> API: POST /events
    API -> V: validate(payload)
    V --> API: ok
    API -> DB: insert LightEvent
    API -> R: evaluate(LightEvent)
    R -> A: create alert
    note right of R
    only if threshold violated
    end note
    API --> S: 202 Accepted
@enduml
      

@startuml
title Sequence Diagram: User Views Room

skinparam shadowing false
skinparam participantStyle rectangle

actor "User" as U
participant "Dashboard" as D
participant "API" as API
database "Read Model DB" as RM

U -> D: open room page
D -> API: GET /rooms/CTC-114
API -> RM: query current state
RM --> API: RoomState
API --> D: JSON RoomState
D --> U: render UI

@enduml
      

@startuml
title Activity Diagram: Ingestion Pipeline
skinparam shadowing false
start
:Receive payload;
:Parse JSON;
if (Schema valid?) then (yes)
  if (Auth ok?) then (yes)
 : Store LightEvent;
 : Update RoomState;
    if (Threshold violated?) then (yes)
   : Create Alert;
    else (no)
    endif
 : Return 202 Accepted;
  else (no)
 : Return 401 Unauthorized;
  endif
else (no)
: Return 400 Bad Request;
endif
stop
@enduml
      

@startuml
title State Machine: Room Light State

skinparam shadowing false

[*] --> Unknown

Unknown --> On: LightEvent state=ON
Unknown --> Off: LightEvent state=OFF

On  --> Off: LightEvent state=OFF
Off --> On: LightEvent state=ON

On  --> Unknown: no events (timeout)
Off --> Unknown: no events (timeout)

@enduml
      

PlantUML Workflow

• Keep .puml in the repo (source of truth)
• Generate SVG artifacts for slides and READMEs
• One diagram answers one question
• Name files by intent and scope

diagrams/
  room_light_layered_component.puml
  room_light_client_server_deploy.puml
  room_light_monolith_component.puml
  room_light_microservices_component.puml
  room_light_event_driven_component.puml
  room_light_sequence_ingest.puml
  room_light_state_machine.puml
        

UML (Unified Modeling Language)

Source (PDF):
OMG UML 2.5.1 Specification (PDF)

Practice Questions

• Which UML diagram shows runtime nodes and network boundaries?
• Which style has the lowest operational overhead?
• Which behavior diagram shows messages over time?
• In event driven design, what contract must remain stable?
• Which structural diagram best shows service boundaries?

Today

Data Architecture First

• Motivation: data centric vs software or hardware centric
• Canonical model: nouns, keys, events, room state
• Normalization: stable interfaces across components
• MongoDB design: collections, indexes, validation
• Schema sharing: embedded ↔ backend ↔ frontend
• Frontend storage: caching and offline
• Evolution: versioning and compatibility rules
• Practice questions

Why Data Centric Architecture

• Data is the shared language between components
• Stable meaning lowers integration cost
• Events create audit trail and replay
• Dashboards require consistent definitions
• Scaling is safer when contracts are explicit

Code changes often; data meaning must remain stable.

Canonical LightEvent

{
  "schema_version": "1.0",
  "event_id": "evt-20260211-000123",
  "event_type": "LightEvent",
  "timestamp": "2026-02-11T08:15:00-08:00",

  "room_id": "CTC-114",
  "device_id": "sensor-ctc-114-01",

  "light_state": "ON",
  "lux": 350,

  "meta": {
    "firmware_version": "0.4.2",
    "battery_pct": 92,
    "signal_rssi_dbm": -58,
    "seq": 9912
  }
}
      

Standard Data Formats (Contract Discipline)

• UUID for stable ids (event_id, alert_id)
• ISO 8601 timestamp with timeroom offset
• Location as stable string key (room_id)
• Enums for states (ON/OFF/UNKNOWN)
• Numbers with units (lux as integer)
• Version in every payload (schema_version)

Where to Validate Schema

• Embedded: build payloads that match the schema
• API: validate JSON schema and return friendly errors
• MongoDB: enforce guardrails with collection validators
• Frontend: validate responses in dev and keep types strict

Rule: validate at the boundary, guardrail at the database.

{
  "collMod": "light_events",
  "validator": {
    "$jsonSchema": {
      "bsonType": "object",
      "required": ["_id","event_id","ts","room_id","device_id","light_state"],
      "properties": {
        "_id": { "bsonType": "string" },
        "event_id": { "bsonType": "string" },
        "ts": { "bsonType": "date" },
        "room_id": { "bsonType": "string" },
        "device_id": { "bsonType": "string" },
        "light_state": { "enum": ["ON","OFF","UNKNOWN"] },
        "lux": { "bsonType": "int", "minimum": 0 }
      },
      "additionalProperties": false
    }
  },
  "validationAction": "error"
}
                                

Alerts are Data

• Alerts are derived from events (rules)
• Store alerts to explain system behavior later
• Alerts are part of the audit trail
• Dashboards can show alert history and status

Store and log decisions as data.

Alert Alg.: Light Stuck ON

• Goal: detect if a room light stays ON too long
• Input: recent LightEvent stream for a room
• Output: Alert document (with explanation)

MongoDB Helps Alerts

• Compound index supports “recent room events”
• Aggregation pipeline can compute durations and windows
• Store alert history for dashboards
• TTL can expire low value alerts if desired

Mongo supports both operational queries and analytic style pipelines.

Alert Alg.: Sudden Lux Drop

• Goal: detect potential sensor obstruction or failure
• Input: sliding window of lux values
• Output: Alert with baseline and delta

Schema Across the Stack

• Keep schema files in the repo (schema/)
• Generate validators for backend (JSON schema)
• Generate types for frontend (TypeScript)
• Embed a minimal mapping table or struct
• Every payload includes schema_version

One schema + language bindings

Frontend Storage Strategy

• Store RoomState snapshots
• Cache selected room_id
• Optionally cache recent events
• Never invent new field names in UI

Practice Questions

• Why validate schema in both API and MongoDB?
• What makes an id stable and trustworthy?
• Why store events separately from room_state?
• What alert fields make debugging easier?

• Room Node: ESP32 + VEML7700 sensor
• Client: Web Dashboard (browser)
• Server: Flask API + MongoDB
• WiFi connects room node to backend
• Internet connects client to backend
• Backend enforces schema and stores events
• Folder Structure

• Embedded builds canonical LightEvent JSON
• Backend API validates schema + enforces rules
• MongoDB stores events, state, alerts
• Frontend reads RoomState projection
• Admin manages rooms, devices, users
• All components share the same schema contract

Module 5

Architectural Decisions: Display Resolution

• Display hardware shapes what you can show
• Resolution affects layout, density, and readability
• Visualization choices depend on pixels and size

Today

• Phone vs embedded vs desktop constraints
• Browser as a display runtime
• Flexbox layout as a response strategy
• Visualization tradeoffs (tables vs charts)
• Practical rules: density, typography, interaction

Key Terms

• Resolution: pixels available (e.g., 1920×1080)
• Pixel density: how packed pixels are (PPI)
• Viewport: usable area in browser or app
• Density: how much data you show at once

Phone (Small Viewport)

• Show fewer columns
• Prefer cards over wide tables
• Summarize first, drill down second
• Touch friendly spacing is non negotiable

Embedded (Fixed Screen)

• Fixed resolution means fixed layout
• Compute limits restrict fancy charts
• Use stable fonts and high contrast
• Prefer simple visuals: status and trend

Desktop (Wide View)

• More columns become usable
• Side by side comparisons are natural
• Filters can remain visible
• Keyboard helps data entry and search

Browser as a Display Runtime

• Same URL can serve multiple screen classes
• Viewport changes during use (resize)
• Device pixel ratio affects rendering
• Responsive layout is an architectural choice

Flexbox (Responsive Layout Tool)

• Natural for rows that wrap into columns
• Good for cards, KPIs, toolbars
• Supports reflow without rewriting HTML
• Pairs well with breakpoints

Visualization Choice Depends on Resolution

• Tables: precise values, many rows
• Charts: trends, comparisons, shape
• Small screens push you toward summaries
• Large screens allow both at once

Architecture Questions to Ask

• What is the smallest supported viewport?
• What must be visible without scrolling?
• What interaction is expected (touch, mouse, none)?
• What is the largest safe table width?
• What is the fallback when charts do not fit?

Takeaway

• Display resolution is a hardware constraint
• Hardware constraints drive UI architecture
• UI architecture shapes data visualization
• Flexbox helps reflow the same content

Treat display as architecture, not styling.

Module 6

Legal Constraints for Industry 4.0 Applications

• Regulatory requirements that shape architecture
• Technical controls tied to legal obligations
• User stories that operationalize compliance

How Legal Requirements Change Over Time

• “Reasonable security” evolves with technology
• Industry standards influence legal expectations
• Older protocols become harder to defend
• Patchability determines long-term compliance

What was acceptable security in 2012 may not be acceptable in 2026.

How Legal Updates Impact Software Updates

• Regulatory guidance evolves (privacy, security expectations)
• New vulnerabilities redefine “reasonable security”
• Industry standards shift (e.g., BLE security, TLS versions)
• Legal exposure increases if systems cannot adapt
• FOTA enables compliance corrections post-deployment
• NFR (security, logging, performance) must support audit defensibility
• Release checklists must include compliance verification

How do legal requirements impact backlog priority?

• Legal risk can override feature urgency
• Security updates may become mandatory
• Regulatory deadlines shift sprint focus
• Unpatchable systems increase liability exposure

When laws or standards evolve, backlog ordering must change. Compliance-driven work can move ahead of features.

Feature First Thinking

• Features drive visible progress
• Bug fixes react to issues
• Legal and security treated as overhead
• Firmware update mechanism delayed

This order increases long-term legal and operational risk.

Legal Risk Forces Reordering

• Privacy violations trigger regulatory exposure
• Security weaknesses increase negligence risk
• Unpatchable devices amplify liability

Legal requirements are structural, not optional.

Legal Requirements Depend on Region

• Laws apply based on where the product is sold or deployed
• Cloud location can affect jurisdiction
• User location may trigger privacy obligations
• Security expectations differ by region

A room light sensor deployed in California, Germany, or Japan may face different regulatory obligations.

FOTA Enables Legal Compliance

• Security patches require remote updates
• Legal defects must be correctable after deployment
• Patch capability reduces long-term exposure

Without secure update capability, compliance cannot be maintained.

Non Functional Requirements (NFR)

• Security
• Performance
• Availability
• Reliability

Legal defensibility depends on security controls and logging.

Mature Engineering Order

• 1. FOTA (update capability)
• 2. Legal compliance
• 3. NFR foundation
• 4. Feature expansion

You cannot promise compliance without patchability.

Legal requirement types

• Wireless compliance (FCC)
• Consumer protection (FTC)
• Privacy rights (CCPA)
• Building energy controls (Title 24)
• Reasonable security (NIST as reference)

Data minimization requirement

• Collect only what is needed for the feature
• Separate identifiers from sensor readings
• Implement retention with TTL, not manual cleanup

Secure update requirement

• Updates must be authenticated and integrity protected
• Failure handling must be safe and recoverable
• Update actions must be auditable

Why this belongs in system design

• Industry 4.0 connects sensors, networks, and decisions
• Legal risk is evaluated through foreseeable harm and reasonable practice
• Privacy, safety, and reliability overlap in deployed systems
• Documentation becomes evidence of due care

Legal outcomes you plan for

• Regulatory enforcement (fines, injunctions, recalls)
• Civil lawsuits (negligence, product liability)
• Contract disputes (SLA, warranties)
• Incident response and breach notification

FCC Part 15 (wireless devices)

• Emissions constraints reduce interference
• Testing and labeling expectations
• Module choices affect certification scope

Deployment safety expectations

• Lighting affects visibility and hazard reduction
• Calibration affects outcomes
• Environment affects sensor accuracy

Device identity and traceability

• Traceability supports recalls and incident response
• Identifiers can become personal data in context

Supply chain risk

• Counterfeit or insecure modules increase exposure
• Third party firmware can carry vulnerabilities

California connected device security expectations (practical)

• Reasonable security features expected for connected devices sold in CA
• Credential hygiene is a core theme

User Story: FCC evidence bundle

User Story: As a release manager, I need to attach RF compliance evidence to each hardware release so we can support certification and audit requests.

Room Light Sensor Example: For the Room 114 sensor batch, the release folder records module certification id and antenna type used.

User Story: Calibration traceability

User Story: As a deployment engineer, I need a calibration and acceptance workflow so the installed system meets safety expectations in real environments.

Room Light Sensor Example: When Room 114 is commissioned, store threshold values and operator id, then schedule recalibration after HVAC season change.

User Story: Secure provisioning

User Story: As a security engineer, I need secure device provisioning so devices cannot be deployed with shared credentials.

Room Light Sensor Example: Provision Room 114 device with unique token; provisioning log records device_id and timestamp, not the secret.

User Story: Hardware revision mapping

User Story: As an incident responder, I need to map incidents to hardware revisions so we can scope impact and recalls accurately.

Room Light Sensor Example: If a sensor batch in Room 114–120 misreports, filter by HW revision and deployment date to scope impact.

User Story: Supply chain evidence

User Story: As a compliance owner, I need supplier and component evidence so we can defend reasonable procurement practices.

Room Light Sensor Example: For each room sensor, store BOM snapshot and confirm no known CVE in the WiFi SDK version.

Product liability and duty of care

• Foreseeable harm drives duty of care
• Defective control logic can create liability
• Safe defaults and clear limitations matter

FTC consumer protection (claims)

• No deceptive accuracy, security, or savings claims
• Statements must match real behavior

Secure update pipeline

• Patchability reduces negligence risk
• Unsafe updates increase exposure

Logging and audit trails

• Logs support dispute resolution and incident response
• Time and integrity matter

Access control and authentication

• Weak auth is often framed as unreasonable security
• Shared credentials are risky

User Story: Signed firmware updates

User Story: As a security engineer, I need firmware updates to be signed and verified so unauthorized code cannot run on devices.

Room Light Sensor Example: When Room 114 sensor updates to v1.3.2, the device logs signature verification success and stores the previous version for rollback.

User Story: Rollback and safe recovery

User Story: As an operations engineer, I need rollback support so devices can recover from failed updates without unsafe behavior.

Room Light Sensor Example: If Room 114 begins toggling rapidly after update, safe mode holds lights steady and rolls back to the last good version.

User Story: Accuracy claim evidence

User Story: As a product owner, I need test evidence for any accuracy claim so we can defend statements under consumer protection scrutiny.

Room Light Sensor Example: If the app claims 95% correct light_state detection, store the test set from rooms with different daylight conditions.

User Story: Default safe state

User Story: As a safety reviewer, I need a documented default safe state so the system behaves predictably when sensor input is missing or inconsistent.

Room Light Sensor Example: If Room 114 sensor stops reporting for 10 minutes, backend sets status to 'unknown' and prevents automated toggles.

User Story: Dashboard access control

User Story: As an administrator, I need role based dashboard access so only authorized users can view or change settings.

Room Light Sensor Example: commonly can view aggregated building statistics, but only building ops can change Room 114 thresholds.

User Story: Rate limiting and abuse protection

User Story: As a backend engineer, I need rate limiting so the system resists brute force and denial of service scenarios.

Room Light Sensor Example: If an attacker spams /api/rooms/114/state, throttle requests and alert ops.

User Story: Operational logging schema

User Story: As an incident responder, I need a consistent logging schema so we can reconstruct timelines and root causes.

Room Light Sensor Example: A single incident report can show: sensor reading spikes → backend decision → UI toggle → operator override.

When sensor data becomes personal data

• Link to person/household via account or device owner
• Infer behavior via patterns (occupancy and schedules)
• Combine with identifiers (device_id, room_id)

California privacy thinking (CCPA style)

• Transparency about collection and use
• Rights often require retrieval and deletion workflows
• Retention should match purpose

Retention and deletion must be implemented

• Retention is not just policy text
• Backups and archives need rules too

Breach readiness

• Incident response steps must be defined
• Preserve evidence and timelines

User Story: Data inventory

User Story: As a privacy owner, I need a data inventory so we know what we collect, where we store it, and why.

Room Light Sensor Example: Inventory explicitly lists: room_id, light_state, timestamp, device_id, and whether each is needed for function.

User Story: Deletion by device_id

User Story: As a user, I want to request deletion of data associated with my device so my data is not retained beyond purpose.

Room Light Sensor Example: Deleting Room 114 device data removes raw readings and severs links from device registry while keeping aggregated anonymous stats.

User Story: Retention TTL policy

User Story: As a system owner, I need automatic TTL deletion so retention is enforced consistently without manual steps.

Room Light Sensor Example: A nightly job expires sensor readings older than 30 days for each room, with a report of deleted counts.

User Story: Data minimization mode

User Story: As a product owner, I need a privacy preserving mode so deployments can reduce risk by collecting fewer identifiers.

Room Light Sensor Example: In privacy mode, payload omits device_id at the API boundary and uses a short lived token instead.

User Story: Access auditing

User Story: As a compliance owner, I need to audit who accessed sensitive data so we can investigate incidents and support accountability.

Room Light Sensor Example: Every request to /api/rooms/114/history is logged with user id and purpose tag.

User Story: Breach runbook

User Story: As an incident commander, I need a breach runbook so the team can respond quickly and preserve evidence.

Room Light Sensor Example: If unauthorized access occurs, the runbook captures affected rooms, timeframe, and exported datasets.

User Story: Data sharing controls

User Story: As a security reviewer, I need controls for third party data sharing so we do not leak more than necessary.

Room Light Sensor Example: If exporting to a building analytics tool, share only aggregated daily counts, not per minute room_id history.

How NIST relates to legal requirements

• Regulators and courts ask about reasonable security
• NIST provides widely accepted frameworks and controls
• Mapping to NIST helps show due care

NIST CSF functions

• Govern
• Identify
• Protect
• Detect
• Respond
• Recover

NIST SSDF (secure development)

• Integrate security into development lifecycle
• Vulnerability handling and patch discipline
• Supply chain awareness (dependencies and firmware)

NIST 800-53 style control families (simplified)

• Access control
• Audit and accountability
• Incident response
• System integrity

User Story: NIST control matrix

User Story: As a compliance owner, I need a control matrix mapping legal expectations to NIST outcomes so we can demonstrate reasonable security.

Room Light Sensor Example: Matrix row: 'reasonable security' → CSF Protect → TLS everywhere → config + penetration test notes.

User Story: CSF based sprint review

User Story: As a project lead, I want to review CSF outcomes each sprint so security controls remain visible and measurable.

Room Light Sensor Example: Sprint demo: show rate limit logs for room endpoints and a dashboard of failed auth attempts.

User Story: Secure release checklist (SSDF aligned)

User Story: As a release manager, I need a secure release checklist aligned with NIST SSDF so releases are consistent and defensible.

Room Light Sensor Example: Release v1.4 includes: signed firmware, TLS config check, TTL job test, rollback test evidence.

Healthcare domain (high stakes)

• HIPAA if tied to patient identity
• Higher expectations for audit and access controls
• Validation and change control are emphasized

Automotive domain (safety critical)

• High expectation for traceability
• Failures can trigger recalls and liability

Retail domain (privacy centric)

• Analytics can become surveillance
• Transparency and minimization reduce risk

Industrial domain (workplace safety)

• Safety and reliability dominate
• Maintenance must be operationalized

Smart buildings / campus (California focus)

• Title 24 energy and control requirements
• Occupancy signals can be sensitive

User Story: Hospital audit logging

User Story: As a hospital security officer, I need audit logs for all configuration changes so we can investigate incidents and meet accountability expectations.

Room Light Sensor Example: Changing Room 114 daylight threshold requires admin role and produces an audit log entry.

User Story: Safety focused fail safe mode

User Story: As a safety reviewer, I need a fail safe mode so inconsistent readings do not create unsafe lighting behavior.

Room Light Sensor Example: If lux value fluctuates near threshold, debounce prevents rapid toggling in Room 114.

User Story: Privacy preserving analytics

User Story: As a building operator, I need privacy preserving analytics so we can report trends without exposing room level behavior.

Room Light Sensor Example: Weekly report shows building-wide counts rather than Room 114 minute-by-minute history.

Project: payload and identifiers

• room_id can be sensitive in context
• device_id should be handled carefully
• timestamps can infer schedules

Project: compliance as user stories

• Convert obligations into backlog items
• Attach evidence artifacts to each story

What to remember

• Map requirements to hardware, software, and data layers
• Use NIST to explain reasonable security and controls
• Evidence is part of the release: tests, logs, diagrams

Module 6

Legal Constraints for Software Updates

• Scope of legal requirements (Federal, State, Sector-Specific)
• How regulations translate into update obligations
• Risk-based patch management expectations
• Evidence and audit readiness as part of release
• Defined accountability for monitoring updates

HIPAA Security Rule (United States)

• Applies nationwide to covered entities & business associates
• Protect electronic health information
• Implement reasonable safeguards
• Ongoing risk management required
• Address known vulnerabilities
• Monitoring Security officer & IT security team

Software Update Implications

• Patch known vulnerabilities promptly
• Maintain documented patch policy
• Log and audit update activity
• Validate updates before deployment

FDA Cybersecurity (United States)

• Applies nationwide to regulated medical device manufacturers
• Secure design lifecycle required
• Postmarket vulnerability monitoring
• Secure update capability required
• Safety validation of changes
• Monitoring: Manufacturer cybersecurity team & quality assurance

Software Update Implications

• Signed firmware updates
• Secure OTA mechanism
• Rollback capability
• Risk impact analysis per release
• Validation test documentation

Module 7

Testing, Verification, Validation

• V-Model definitions
• Test levels + V‑Model
• TDD + AAA
• Unit / Component / Integration / System / Acceptance
• API testing for IoT ingestion

Testing vs Verification vs Validation

• Verification: artifact correctness (req/design/code)
• Validation: user/business fit
• Testing: defect discovery by execution

Verification

• Requirements review
• Design review
• Code review
• Static analysis

Validation

• Acceptance testing
• Usability + trust checks
• Field trials

Test Levels

• Unit: function/module
• Component: service boundary
• Integration: service + DB/cache/queue
• System: end-to-end stack
• Acceptance: user scenarios

The Goal of Testing

Testing Characteristics by Level

UNIT
- Many tests
- Very fast
- Fully automated
- Run on every commit
- Low cost per test

COMPONENT
- Fewer than unit
- Automated
- Slightly slower
- Mock dependencies

INTEGRATION
- Moderate count
- Slower (DB/network)
- CI pipeline stage
- Real infrastructure

SYSTEM
- Few tests
- Much slower
- Staging environment
- Full stack

ACCEPTANCE
- Very few
- Often manual or semi-auto
- Business validation
- Highest execution cost
      

Development ↔ Testing + Roles

LEFT SIDE (Build)           RIGHT SIDE (Test)        ROLE

Requirements        ↔  Acceptance Test        Client / Product Owner
System Design       ↔  System Test            QA / Test Engineer
Component Design    ↔  Integration Test       QA + Dev
Implementation      ↔  Unit Test              Developer

Key Idea:
Each development artifact has a matching
verification activity and responsible role.
      

Sensor Payload (contract)

{
  "device_id": "ls-0081",
  "room_id": "CTC-114",
  "lux": 312,
  "light_state": "ON",
  "timestamp": "2026-02-23T08:15:30Z",
  "fw_version": "1.2.0",
  "nonce": "c4b8f0c3-2a0d-4d25-9f1c-acde1b7b7b8a"
}
        

AAA: Arrange: Act: Assert

History
- Popularized with early xUnit frameworks
- Strongly adopted with TDD (2000s)
- Became standard structure for unit tests

Concept
Arrange → Prepare inputs + environment
Act     → Execute behavior
Assert  → Verify outcome

Core Principle:
One behavior per test.
      

TDD + AAA

TDD loop:
1) Write failing test
2) Implement minimum to pass
3) Refactor (keep tests green)

AAA:
- Arrange
- Act
- Assert
        

Unit: validatePayload Function

// validatePayload.js

function validatePayload(p) {
  if (!p.device_id) return "missing_device_id";
  if (!p.room_id) return "missing_room_id";
  if (p.lux < 0 || p.lux > 20000) return "bad_lux";
  if (p.light_state !== "ON" &&
      p.light_state !== "OFF" &&
      p.light_state !== "AUTO") return "bad_state";
  return "ok";
}
      

Unit: validatePayload Function

// validatePayload.js

function validatePayload(p) {
  if (!p.device_id) return "missing_device_id";
  if (!p.room_id) return "missing_room_id";
  if (p.lux < 0 || p.lux > 20000) return "bad_lux";
  if (p.light_state !== "ON" &&
      p.light_state !== "OFF" &&
      p.light_state !== "AUTO") return "bad_state";
  return "ok";
}
      

Incorrect Implementation

// validatePayload.js (BUGGY VERSION)

function validatePayload(p) {
  if (!p.device_id) return "missing_device_id";
  if (!p.room_id) return "missing_room_id";

  // ❌ BUG: wrong logic (should be OR, not AND)
  if (p.lux < 0 && p.lux > 20000) return "bad_lux";

  if (p.light_state !== "ON" &&
      p.light_state !== "OFF" &&
      p.light_state !== "AUTO") return "bad_state";

  return "ok";
}
      

Unit: validatePayload Function

// validatePayload.js

function validatePayload(p) {
  if (!p.device_id) return "missing_device_id";
  if (!p.room_id) return "missing_room_id";
  if (p.lux < 0 || p.lux > 20000) return "bad_lux";
  if (p.light_state !== "ON" &&
      p.light_state !== "OFF" &&
      p.light_state !== "AUTO") return "bad_state";
  return "ok";
}
      

Component: API Handler

// Simple handler

function postLight(req) {

  if (req.body.lux < 0 || req.body.lux > 20000) {
    return { status: 400, saved: false };
  }

  return { status: 201, saved: true };
}
      

Component Testing with Postman

• Test API endpoints
• Verify status codes
• Validate JSON responses
• Test authentication
• Check error handling
• Simulate bad input

cURL Example

curl -X POST http://localhost:3000/api/v1/telemetry/light \
  -H "Content-Type: application/json" \
  -d '{
    "device_id":"ls-1",
    "room_id":"CTC-114",
    "lux":300,
    "light_state":"ON"
  }'
      

Component Test (AAA): Valid

# Arrange
Valid JSON payload

# Act
curl -X POST http://localhost:3000/api/v1/telemetry/light \
  -H "Content-Type: application/json" \
  -d '{"lux":300,"light_state":"ON"}'

# Assert
201
{ "saved": true }
      

Integration Test (AAA): Backend

// Arrange
Valid payload ready

// Act
POST /api/v1/telemetry/light
{
  "room_id": "CTC-114",
  "lux": 300,
  "nonce": "n-1"
}

// Expect backend to write to DB
      

System Test (AAA)

# Arrange
System deployed
Sensor online
Room CTC-114 exists
      

Risks

• Slow execution
• Expensive environment
• Hard to debug failures
• Multiple components involved
• Flaky tests (network, timing)

Validation

• User needs
• Business goals
• Real-world usefulness

Early Validation

• Prototype first
• Less formal testing
• Fast feedback
• Low cost of change

Verification

Module 8

Automation: V-Model & Agentic AI

• Automation foundations
• Verification vs Validation vs Testing
• GenAI vs AI Agentic vs Agentic AI
• IoT Light Sensor App use case
• LangChain + Ollama setup (VS Code)