DCP‑400 – Implementation

Document ID: DCP‑400

Project Title: [Smart Lab Sensor Network]

Team: [Team name / number]

Revision: Rev [1.0]

Date: [YYYY‑MM‑DD]

Related Documents:

• DCP‑100A – Project Proposal
• DCP‑100B – Stakeholder Requirements
• DCP‑200 – System Requirements
• DCP‑300 – Design
• DCP‑500A/B/C – Verification & Validation (future)

1. Purpose and Scope

This document (DCP‑400) records the implementation of the system defined in DCP‑300, including:

• The implementation items (IMP-*) that realize the designed components (CMP-*).
• The configuration management (CM) approach used to control code, hardware, and documentation.
• The build and deployment procedures required to reproduce the implemented system.
• A change log of approved modifications to requirements or design during implementation.
• The project’s readiness for verification (Stage 6 / Stage 7).

This document covers Stage 5 of the capstone V‑Model lifecycle (Implementation / Construction).

2. References

List the standards, course documents, and internal references that govern implementation and CM.

• ISO/IEC/IEEE 15288:2023 – Systems and software engineering — System life cycle processes (Implementation, Configuration Management).
• ISO/IEC/IEEE 29148:2018 – Requirements engineering (requirements quality & traceability).
• DCP‑100A – Project Proposal (ConOps, stakeholder list).
• DCP‑100B – Stakeholder Requirements (StRS, STR-*).
• DCP‑200 – System Requirements (SyRS/SRS, REQ-*).
• DCP‑300 – Design (Architecture, CMP-*, interfaces).
• DCP‑RTM – Requirements Traceability Matrix (current baseline).
• Internal coding standards: [e.g., “Team C++ Style Guide v1.2”].
• Hardware/PCB design rules: [e.g., “KiCad 4‑layer layout rules for lab manufacturing”].

3. System Overview (From Design to Implementation)

Provide a brief summary of the system and how its implementation is organized, referencing DCP‑300.

3.1 System Description (Summary)

The project is a [brief description, e.g., “wireless sensor network for monitoring temperature and humidity in teaching labs”].

The system comprises:

• Sensor Nodes: [e.g., battery‑powered LoRa nodes measuring temperature/humidity].
• Gateway: [e.g., LoRaWAN gateway forwarding data to server].
• Backend Server: [e.g., Python API + database storing time‑series data].
• Dashboard UI: [e.g., web front‑end for lab technicians].

3.2 Mapping of Design Components to Implementations

The architecture and component breakdown are defined in DCP‑300.

Implementation in Stage 5 realizes each component (CMP-*) through one or more implementation items (IMP-*), as documented in Section 4 (Implementation Items).

:::

This section is a bridge from DCP‑300 (design) to this document (implementation).

Keep it short; details belong in Section 4.

4. Implementation Items (IMP-*)

This section lists all implementation items that realize the designed components (CMP-*).

Each IMP-* ID should be traceable in the RTM and in your repositories.

4.1 Implementation Item Summary Table

[Extend this table for all implementation items.]

4.2 Implementation Item Descriptions

Provide short, focused subsections for each significant IMP-* item or group of related items.

4.2.1 IMP‑SW‑010A – Dashboard UI

• Related Component(s): CMP-SW-010 – Dashboard UI Module.
• Purpose: Provides a web interface for lab technicians to view real‑time and historical temperature/humidity data and configure alert thresholds.
• Technologies:
  • Front‑end: Vue 3
  • Build tool: Vite
  • API interface: REST over HTTPS to backend server (IMP-SW-030A).
• Repository / Path: git@gitlab:teamX/labdash-ui.git
  • Main branch: main
  • Stage‑5 baseline tag: ui-v0.9-stage5-trr
• Key Files / Modules:
  • src/views/DashboardView.vue – main dashboard view.
  • src/components/AlertConfigPanel.vue – alert configuration UI.
  • src/api/client.ts – API client, implements calls for REQ-SW-020, REQ-SW-021.
• Traceability Notes:
  • Implements functions derived from REQ-SY-010, REQ-SW-020, REQ-SW-021.
  • Code comments reference relevant IDs, e.g., // REQ-SW-020: display real-time lab status.

4.2.2 IMP‑SW‑020A – Node Firmware

• Related Component(s): CMP-SW-020 – Node Control & Telemetry Firmware.
• Purpose: Reads temperature/humidity sensors, manages power modes, formats packets, and communicates via LoRa to gateway.
• Technologies:
  • MCU: STM32L072
  • Language: C (ARM‑GCC), FreeRTOS 10.4.
• Repository / Path: git@gitlab:teamX/node-fw.git
  • Main branch: main
  • Stage‑5 baseline tag: node-fw-v0.8-stage5-trr
• Key Files / Modules:
  • src/main.c – system entry, task creation.
  • src/sensor_task.c – sensor read + calibration (REQ-SY-010).
  • src/radio_task.c – LoRa MAC + transmit path (REQ-SY-011).
  • src/power_manager.c – sleep/wake logic (REQ-SY-0xx, battery life).
• Traceability Notes:
  • Modules contain comments with CMP-* and REQ-* references.
  • Implements IMP-SW-020A in RTM: CMP-SW-020 → IMP-SW-020A.

4.2.3 IMP‑SY‑040A – Sensor Node PCB rev B

• Related Component(s): CMP-SY-040 – Sensor Node Hardware.
• Purpose: Provides physical platform (MCU, radio, sensors, power) for each node.
• Tools: KiCad 7, manufacturer: JLCPCB.
• Project Path: kicad_projects/sensor_node_revB/
• Revision & Baseline:
  • Schematic: sensor_node_revB.sch (Rev B, dated 2026‑03‑10).
  • Layout: sensor_node_revB.kicad_pcb (4‑layer, 1 oz copper).
  • BOM: BOM_sensor_node_revB_v1.1.xlsx.
• Assembly:
  • Three boards assembled; two fully populated, one partially for diagnostics.
  • Rework notes: R27 changed from 100 kΩ to 47 kΩ; see Change Log entry CR‑007.
• Traceability Notes:
  • Realizes CMP-SY-040; supports requirements REQ-SY-010, REQ-SY-011, REQ-SY-0xy (supply voltage/EMC constraints).

[Add similar subsections for each major IMP-* as needed.]

5. Configuration Management

Describe how you identify, control, and track configurations for HW, SW, and docs.

5.1 Configuration Management Strategy

• Version Control System: Git (GitLab university instance).
• Repositories:
  • labdash-ui – UI front‑end.
  • backend – server backend.
  • node-fw – node firmware.
  • hardware – KiCad projects (sensor node, gateway shield).
  • tools – calibration & deployment scripts.
• Branching Model:
  • Protected main branch in each repo.
  • Feature branches named feature/<short-description>.
  • Pull requests (merge requests) required; at least one peer review before merge.
• Tagging / Releases:
  • Tags with pattern <component>-v<major>.<minor>-stage5-trr used for Stage‑5 baseline.
  • Example: node-fw-v0.8-stage5-trr.
• Configuration Items (CIs):
  • CI‑SW‑UI – Dashboard UI repo at tag ui-v0.9-stage5-trr.
  • CI‑SW‑FW – Node firmware repo at tag node-fw-v0.8-stage5-trr.
  • CI‑SW‑BE – Backend repo at tag backend-v0.6-stage5-trr.
  • CI‑HW‑SN‑REV‑B – Sensor node PCB rev B + BOM v1.1.

5.2 Baselines

Identify the key baselines relevant to implementation.

• Design Baseline (End of Stage 4):
  • DCP‑300 Rev 1.0 approved on 2026‑03‑01.
  • RTM baseline RTM-v1.0 (no IMP-* yet).
• Implementation Baseline (Stage 5 – TRR):
  • DCP‑400 Rev 1.0 (this document).
  • RTM baseline RTM-v1.2 (with CMP-* → IMP-* links updated).
  • CIs included:
    • CI‑SW‑UI @ tag ui-v0.9-stage5-trr.
    • CI‑SW‑FW @ tag node-fw-v0.8-stage5-trr.
    • CI‑SW‑BE @ tag backend-v0.6-stage5-trr.
    • CI‑HW‑SN‑REV‑B assembled boards (SN: 001, 002, 003).

5.3 Status Accounting

Provide an overview of current configuration status.

• All code repositories compile and build successfully using the procedures in Section 6.
• All three sensor node boards are functioning with firmware node-fw-v0.8-stage5-trr.
• Backend and UI are deployed in the lab test environment (see Section 6.3).
• Open issues at Stage‑5 freeze:
  • Issue #34 – UI occasionally fails to refresh after network outage (low severity).
  • Issue #37 – Sensor node rev B has slightly higher than expected quiescent current; mitigated in firmware but hardware fix deferred to rev C.

6. Build, Flash, and Deployment Procedures

Provide step‑by‑step instructions to reproduce your implementation from scratch.

Assume a capable but unfamiliar engineer is following this.

6.1 Common Prerequisites

• Host OS: Ubuntu 22.04 LTS (verified); Windows 11 (development use, not primary baseline).
• Common Tools:
  • Git 2.40+
  • Python 3.11 + pip
  • Docker 24+ (for backend deployment)

6.2 Firmware Build & Flash Procedure (Node Firmware – IMP‑SW‑020A)

1. Clone the repository

   git clone git@gitlab:teamX/node-fw.git
   cd node-fw
   git checkout node-fw-v0.8-stage5-trr
   

2. Install toolchain

   • Install ARM‑GCC toolchain gcc-arm-none-eabi-10-2020-q4-major or later.
   • Install CMake 3.22+.

3. Configure and build

   mkdir build
   cd build
   cmake .. -DCMAKE_BUILD_TYPE=Release
   make -j4
   

   Expected output: build/node_fw.elf, build/node_fw.hex.

4. Flash firmware to node

   • Connect ST‑Link V2 to node SWD header.

   • Use openocd or STM32CubeProgrammer:

     st-flash write node_fw.hex 0x8000000
     

5. Verify basic bring‑up

   • Connect USB‑UART.
   • Power board with 3.7 V Li‑ion battery.
   • Confirm console log shows “Node FW v0.8 – Stage 5” and periodic sensor readings.

6.3 Backend Build & Deployment Procedure (IMP‑SW‑030A)

1. Clone and checkout baseline

   git clone git@gitlab:teamX/backend.git
   cd backend
   git checkout backend-v0.6-stage5-trr
   

2. Dockerized deployment (preferred)

   docker compose up -d
   

   • Services started: api, db.
   • API available at http://localhost:8000/api/v1/.

3. Initialize database

   docker exec -it backend_api_1 alembic upgrade head
   

4. Smoke test

   curl http://localhost:8000/api/v1/health
   

   Expected response: {"status": "ok", "version": "0.6-stage5-trr"}

6.4 UI Build & Serve Procedure (IMP‑SW‑010A)

1. Clone and checkout baseline

   git clone git@gitlab:teamX/labdash-ui.git
   cd labdash-ui
   git checkout ui-v0.9-stage5-trr
   

2. Install dependencies

   npm install
   

3. Configure backend URL

   • Edit .env file: VITE_API_URL=http://localhost:8000/api/v1

4. Run development server

   npm run dev
   

   • UI should be accessible at http://localhost:5173.

6.5 Hardware Assembly & Power‑On Procedure (IMP‑SY‑040A)

1. Assemble sensor node PCB rev B

   • Order bare boards from sensor_node_revB_gerbers.zip.
   • Use BOM BOM_sensor_node_revB_v1.1.xlsx.
   • Follow assembly notes in assembly_notes_revB.md.

2. Initial checkout

   • Inspect for shorts and solder bridges.
   • Apply 3.7 V from lab supply with current limit 200 mA.
   • Check key rails: 3.3 V, 1.8 V within ±5% of nominal.

3. Apply firmware

   • Follow Section 6.2 to flash.
   • Confirm LED heartbeat and UART logs.

7. Traceability to Requirements and Design

Summarize how implementation items relate back to requirements and design.

7.1 RTM Extensions (CMP-* → IMP-*)

The RTM has been updated to include links from design components to implementation items.

Excerpt from RTM (simplified):

The full RTM is maintained separately as RTM-v1.2.xlsx and is under configuration control (see Section 5).

7.2 Deviations and Justifications

Document any known deviations where implementation currently differs from design or requirements (before change control is fully applied).

• Deviation D‑001:
  • REQ-SY-011 specifies 60 s update interval.
  • IMP-SW-020A currently configured for 120 s updates to conserve battery, pending CR‑005 approval.
  • Impact: slower update frequency; stakeholders informed and accepted for prototype testing.
• Deviation D‑002:
  • UI mock‑up in DCP‑300 (Fig. 4‑2) differs from implemented layout (IMP-SW-010A): chart moved to top, alerts panel on the right.
  • No requirements impacted; cosmetic change only.

8. Change Log (Implementation Phase)

Record approved changes that affected implementation during Stage 5.

CR‑003 – Change of Temperature Sensor

• Reason: Original SHT31 became unavailable in required lead time; SHTC3 chosen as drop‑in replacement with slightly different I²C address and accuracy.
• Impact Analysis:
  • REQ-SY-010 still satisfied (±0.5°C accuracy met per datasheet and bench tests).
  • Minor firmware change (sensor_task.c); BOM updated.
• Decision: Approved by advisor; implemented in rev B boards.
• Documentation Updated: DCP‑200, DCP‑300, DCP‑400, RTM‑v1.2.

[Add short descriptions for each CR as needed.]

9. Known Issues and Limitations (Pre‑Verification)

List known technical issues at the end of Stage 5 and any temporary workarounds, so that Stage 6/7 test planning can account for them.

10. Readiness for Verification (Stage 6 / Stage 7)

Summarize why the system is ready to enter formal verification.

10.1 Implemented Requirement Coverage

• As of baseline RTM-v1.2:
  • Total system requirements (REQ-*): 35
  • Requirements implemented by at least one IMP-*: 29
  • Requirements not yet implemented: 6 (primarily stretch goals and non‑critical features).

Key requirements implemented:

• REQ-SY-010 – Temperature measurement range & accuracy (nodes implemented and calibrated).
• REQ-SY-011 – Periodic transmission (currently 120 s per CR‑005).
• REQ-SW-020 – Alert generation on high temperature.
• REQ-SW-021 – Dashboard displays current status of all labs.

10.2 Build & Deployment Stability

• Firmware, backend, and UI builds are repeatable using procedures in Section 6.
• Test environment with at least 3 nodes and 1 gateway can be reliably brought up within 30 minutes from a clean repo checkout.

10.3 Entry Criteria for Stage 6/7

The following entry criteria for Stage 6 (Unit / Component Verification) and Stage 7 (System / Integration Verification) are met:

• Implementations for CMP-SW-020, CMP-SW-030, CMP-SW-010, CMP-SY-040 are complete to Stage‑5 scope.
• Baseline tags established and recorded in CM section.
• Known issues documented (Section 9) and do not block planned verification activities.
• DCP‑400 and RTM updated and under version control (RTM-v1.2).

11. Approvals

Prepared by:

• Name: [Student A] — Role: [Firmware Lead] — Signature: ___________________ Date: __________
• Name: [Student B] — Role: [Hardware Lead] — Signature: ___________________ Date: __________
• Name: [Student C] — Role: [Backend / UI Lead] — Signature: ___________________ Date: __________

Reviewed and Approved (Stage 5 Gate – TRR):

• Name: [Faculty Advisor] — Role: [Capstone Supervisor] — Signature: ___________________ Date: __________
• Name: [Client / Stakeholder Rep, if applicable] — Role: [Sponsor] — Signature: ___________________ Date: __________