Generic Parameter Management & Sensor Integration
Measurement Systems with Modern and Legacy Frontends
1) Problem Context (clear even for non-experts)
Modern measurement devices rarely consist of a single platform. In practice, the system landscape included:
- PC-based systems with a web-based user interface
- Legacy display & measurement devices (compact, oscilloscope-like units)
- Multiple communication protocols and interfaces
- A shared set of sensors and device configuration data
The core challenge: How can configuration and runtime data be managed consistently, safely, and correctly across such a heterogeneous system — without duplicating logic or creating architectural chaos?
2) Architectural core idea
I designed and implemented a generic, type-safe Parameter Manager that became the single source of truth for both device configuration and runtime operational data.
Guiding principle: one data model · multiple representations · no dependency on UI or communication protocols.
3) What the Parameter Manager really is
This was not just a parameter container, but a complete model of the device state.
- Supported data types:
bool,int,double(extensible without changing existing code) - Implemented using C++ templates → strict compile-time type safety
- No
void*, no runtime casting; invalid parameter usage eliminated at compile time
In plain words: the interface was designed so that the code cannot be used incorrectly.
4) Persistent storage architecture: NvM → RAM
All configuration and operational data was:
- Persistently stored in non-volatile memory (NvM)
- Fully loaded into RAM during device startup
During normal operation, the system worked exclusively on the RAM-resident copy; NvM was used only for initialization and saving changes.
- High performance
- Deterministic behavior
- Clean separation between runtime logic and persistence
5) Optimization for real embedded constraints
The Parameter Manager was not a one-size-fits-all container. The design considered embedded limitations:
- Template-based structures for structured parameters
- Linked-list-based handling for boolean parameters
- Compact boolean representation for efficient NvM storage
6) Integration into a real system
The same parameter model was reused unchanged across:
- PC-based systems with web visualization
- Legacy display and measurement devices
- Different communication protocols
Business logic was not duplicated; UI and protocol specifics had no impact on the underlying data model.
7) Reuse as proof of architectural value
This Parameter Manager was not a one-off solution. It was successfully reused across three major projects:
- Core project: development of a generic, reusable Parameter Manager as an architectural foundation
- Integration project: introduction into an existing legacy codebase and implementation of a new communication line
- Legacy device extension: support for compact oscilloscope-like devices using a different protocol — without changes to the core parameter model
8) Architectural outcome
- Single source of truth for configuration and runtime data
- Clear decoupling between data model, UI, and communication layers
- Scalable and reusable architecture
- Long-term maintainability across heterogeneous systems
Strong abstraction and type safety transformed a complex, mixed-generation measurement system into a maintainable and scalable architecture.