SENS
Sensor Logic Units
1. Overview
Sensor Logic Units (SENS) are micro-engines within the ZAYAZ Computation Hub responsible for processing, verifying, and conditioning sensor- or IoT-based data streams.
SENS engines operate at the interface between the physical world and digital processing. They apply device-aware logic to ensure that raw sensor signals are trustworthy, well-formed, and suitable for downstream computation.
SENS is an engine type within the MICE taxonomy.
Concrete implementations are registered as micro-engine instances (MEIDs) that implement the SENS type.
2. Design Principles
-
Device Awareness
SENS engines are explicitly aware of sensor type, device characteristics, and data acquisition context. -
Physical Plausibility
Sensor readings are evaluated against physical and operational constraints. -
Non-Inferential Processing
SENS engines do not estimate missing values or infer intent; they condition and verify observed signals.
3. Scope of Responsibility
3.1. What SENS Engines Do
- Validate sensor-originated data streams
- Apply device-specific plausibility checks
- Detect sensor drift, saturation, or malfunction
- Filter raw sensor noise
- Verify sampling intervals and data continuity
- Flag anomalous or suspicious readings
Typical sources include:
- Smart meters
- Building Management Systems (BMS)
- Industrial IoT devices
- Environmental sensors
- Telemetry feeds from operational equipment
4. What SENS Engines Do Not Do
- ❌ Compute ESG metrics or indicators (CALC)
- ❌ Aggregate data across entities or time (AGGR)
- ❌ Transform units or formats for interoperability (TRFM)
- ❌ Estimate or fill missing data (SEM)
- ❌ Apply source-agnostic time-series logic (TSER)
SENS engines are source-bound and device-specific by design.
5. Inputs
SENS engines consume:
- Raw sensor or IoT data streams
- Device metadata (sensor type, calibration info, expected ranges)
- Sampling configuration and operational constraints
Inputs typically originate directly from:
- IoT gateways
- Streaming ingestion pipelines
- Device APIs
6. Outputs
SENS engines produce:
- Conditioned sensor data streams
- Sensor-quality flags and annotations
- Device health or plausibility indicators
- Provenance references to original sensor inputs
Outputs from SENS engines are commonly consumed by:
- TSER (generic time-series processing)
- VALI (schema and constraint validation)
- TRFM or CALC (after conditioning)
7. Audit & Provenance
Every SENS execution records:
- Source device identifiers
- Applied plausibility and validation rules
- Detected anomalies or flags
- Execution timestamps and engine version
This information is captured in ALTD / DAL logs, enabling:
- sensor-level traceability,
- forensic analysis,
- verifier inspection of raw data integrity.
8. Canonical Identification
- Engine Type:
SENS - USO Code:
SENS - Category: Micro Engine (MICE)
- Layer: Computation Hub
SENS identifiers are used consistently across:
- execution logs,
- provenance records,
- USO semantic classification.
9. Design Rationale
Separating sensor logic into a dedicated engine category ensures that:
- physical-world assumptions are explicit,
- device behavior is auditable,
- downstream computations are shielded from unreliable inputs,
- sensor-derived signals are clearly distinguishable from inferred or computed data.
SENS makes trust in physical data a first-class architectural concern.
10. Related Engine Types
- TSER — Time-Series Engines
- VALI — Validation Engines
- TRFM — Transformation Engines
- CALC — Calculation Engines
Status: Stable
Owner: Computation Hub / MICE