FluxView Report — Full Text (Existing Work / Requirements / System Spec)

Full text of our "Existing Work, Problem Identification, Gap Analysis, Requirements, and System Specification Report" (25% of grade, due Sep 23). This entry has all the WRITING — the 8 required diagrams (flowchart, context model, use-case, sequence, UML class, ER diagram, Gantt timeline, UI wireframe) only exist as images inside the actual Word file, which Raylen has and can share directly (ProjectPulse doesn't support file uploads, only text and links). Ask Raylen for FluxView_Report_DRAFT.docx if you need the real file with diagrams. ABSTRACT Environmental data collected at the Prairie View A&M University (PVAMU) research farm — including rainfall, humidity, soil moisture, and eddy-covariance flux tower measurements of greenhouse gas exchange — is currently gathered by scientists and by Shell's Nature and Environmental Technology (NET) program, but it is not easily accessible to the students, farm staff, and community members who could benefit from it. Anyone who wants to know what conditions looked like on the farm last week, rather than just today, currently has to request that data directly from the research team or log into a specialized platform not built for casual use. This project, developed as the Data Visualization workstream of the Shell NET–PVAMU capstone portfolio, addresses that gap by building a mobile-friendly dashboard (FluxView) that ingests timestamped environmental readings through a documented API, stores them with quality-assurance flags, and presents both real-time conditions and historical trends through simple charts, a farm map, and threshold-based alerts. 1. INTRODUCTION 1.1 Problem Statement Environmental data collected at the PVAMU research farm — rainfall, humidity, soil moisture, and eddy-covariance flux tower measurements of greenhouse gas exchange — is currently collected and stored by scientists and by Shell's Nature and Environmental Technology (NET) program, but it is not accessible to non-expert users in a simple, self-service way. Farmers, students, and the broader Prairie View community have no way to check current or historical environmental conditions for the farm the way they might check a weather app: anyone who wants that information today has to log into a specialized research platform or request it directly from the team. This creates a gap between the value of the data being collected and the number of people who can actually use it to understand what is happening on the farm over time. 1.2 Background or Related Work Several categories of existing systems are related to this project, and each falls short of what the Shell NET–PVAMU community needs: - General consumer weather apps (e.g., Apple Weather, Weather.com) provide current conditions and short-term forecasts, but almost never expose historical trend data beyond the past day or two, and have no concept of a specific research farm or of flux-tower-derived metrics such as net ecosystem exchange. - FLUXNET's public data portal is a legitimate existing system for sharing flux tower data across research sites worldwide, but it is oriented toward researchers downloading raw CSV files for offline analysis, not toward a mobile-friendly, at-a-glance dashboard for non-expert users. - Shell's own internal visualization tools (referenced by the sponsor team during our requirements call) let Shell scientists visualize their data, but these tools are not built for public, student, or community access, and are not integrated with the specific PVAMU farm dataset. - Manual, ad hoc logging — the current de facto approach described by the sponsor — requires anyone who wants historical context to separately request it or dig through internal systems, rather than simply opening an app. Taken together, the gap this project addresses is not a lack of data — PVAMU and Shell already collect rich environmental data through eight eddy-covariance flux towers (operating since May 2023) as part of Prof. Ram Ray's "Enhancing Soil Carbon Sequestration by Implementing Innovative Tools and Interventions under Different Ecosystems" project — but a lack of an accessible, historically-aware, mobile-friendly way to view it. [Team note: add 2-3 real citations here via Zotero before final submission — search "environmental monitoring dashboard," "precision agriculture data visualization," "eddy covariance data portal usability." We deliberately did not invent citations.] 1.3 Objectives - Define and implement a data schema and ingestion path that can accept Shell/PVAMU flux tower and weather data, with timestamps, units, and QA/QC flags. - Build a mobile-friendly web dashboard exposing current conditions, historical trend charts, and simple map context for the PVAMU farm site. - Add threshold-based alerting so out-of-range or anomalous conditions are surfaced automatically. - Provide simple CSV export so researchers and community users can pull data out for their own analysis. - Establish a documented API and common data schema so the Predictive Analytics workstream (Project 3 of the Shell NET portfolio) can plug forecast overlays into this dashboard later. 1.4 Our Approach Build a thin vertical slice end-to-end first — ingest one variable, store it, and chart it — rather than fully building each architectural layer in isolation. Validate the whole pipeline early using sample or historical data while the live Shell data-transfer process is finalized. Prioritize "must-have" dashboard views (current conditions and historical trend charts) ahead of polish features (maps, CSV export). Avoid overpromising on data completeness or accuracy — aim for a credible prototype, not a production-certified monitoring system.

• 2. METHODS
• 2.1 Requirement Engineering & Specification — Functional Requirements: FR1 ingest timestamped readings via documented API; FR2 tag every reading with a QA/QC flag (valid/suspect/missing); FR3 display current conditions on a dashboard home view; FR4 let a user pick a date range and view historical trend charts; FR5 let a user export displayed data as CSV; FR6 let a signed-in team member configure an alert threshold; FR7 notify a subscribed user when a reading crosses a threshold; FR8 fully mobile-responsive layout, no horizontal scrolling.
• Non-functional Requirements: NFR1 initial charts load within 3 seconds for a 30-day range; NFR2 retain at least 12 months of historical readings; NFR3 degrade gracefully with a clear "no data" state rather than crashing; NFR4 WCAG-AA color contrast and full keyboard navigability; NFR5 credentials/API keys never committed to the public repo.
• Requirement specifications: FR4 implemented as a GET /api/readings endpoint (site_id, variable, start, end params) returning JSON; FR7 implemented by evaluating a sensor's alert rules on every new ingested reading (not on a polling schedule), writing an alert_events row and pushing a notification when a rule matches.
• 2.2 System Design — diagrams only exist in the Word file: Figure 1 method flowchart (data source -> ingestion -> database -> query API -> dashboard, plus a parallel alert engine path); Figure 2 context model (system vs. Shell data provider, weather feed, researchers, students/admins, community users); Figure 3 use-case diagram (Community/Farm user, Researcher, Team admin actors); Figure 4 sequence diagrams for two scenarios (viewing historical trends; a threshold alert firing); Figure 5 UML class diagram (User, Site, Sensor, Reading, AlertRule, AlertEvent).
• 2.3 Algorithm Design — time-bucketed aggregation (resample raw readings into a requested granularity via a single O(n) pass using a hash map keyed by bucket timestamp); threshold alert evaluation (on each new reading, look up only that sensor's rules, O(k) where k = rules per sensor, triggered once per ingested reading).
• 2.4 Database Design — PostgreSQL, Figure 6 ER diagram: sites -> sensors -> readings (one row per reading, each carrying its own QA flag); sensors -> alert_rules -> alert_events, referencing users to notify.
• 2.5 AI and Industry Standards — the dashboard itself uses no ML directly (that's Project 3's scope), but any future forecast overlay will follow NIST's AI RMF Govern/Map/Measure/Manage structure and will never present predictions with more certainty than the data supports.
• 2.6 Security Design — auth required for admin actions only, public views stay read-only; row-level security in Postgres restricts admin-only tables; all traffic over HTTPS, Shell API keys as server-side env vars only, never exposed to the browser; incident response follows the NIST Cybersecurity Framework's Identify/Protect/Detect/Respond/Recover structure.
• 2.7 Timeline and Milestones — Figure 7 Gantt chart: kickoff/sponsor call and existing-work review (mid-late Sep) -> this report + presentation (Sep 23) -> wireframes/schema design (late Sep) -> ingestion API + DB prototype (Oct) -> dashboard front-end (Oct-Nov) -> alerting + accessibility pass (Nov) -> integration testing (late Nov) -> Semester 1 demo + progress report (Dec 2026).
• 2.8 User Interface Design — no working screens exist yet (design phase only); Figure 8 is a labeled wireframe, not a screenshot. Planned views: Home/Current Conditions (temp/humidity/soil/CO2 cards + map marker); Trends (date-range picker + chart + CSV export); Alerts (active threshold exceedances, missing-data warnings); Admin, sign-in only (manage data sources, QA flags, alert thresholds).
• 3. REFERENCES — PVAMU-Shell Capstone Project Description (sponsor brief); FLUXNET2015 Dataset (fluxnet.org); NIST Cybersecurity Framework (nist.gov/cyberframework); NIST AI Risk Management Framework (nist.gov/itl/ai-risk-management-framework). Team still needs to add 2-3 Zotero literature citations to section 1.2 before final submission.