Commission the entire path: source, instrument, calculation, view, and responsible reviewer. A single reading can test all five.
Start with the review question.
Before choosing a dashboard layout or connection type, write down the questions the monitoring team expects to answer. Which structure or work area is being observed? Which variables are relevant? Over what period will they be reviewed, and by whom? A clear question makes it easier to choose a useful project structure and a manageable initial scope.
Separate data availability from engineering interpretation. The data workflow should establish the identity, timestamp, unit, and processing context of a reading. The monitoring procedure should define its engineering meaning and the response to conditions that merit attention. Both need an owner, even when the same person performs both roles.
- Name the monitored work areas and assets.
- Identify the variables and periods that inform each review.
- Assign the people who configure, operate, and interpret the workflow.
Agree what each reading means.
Create a small instrument register with stable field identifiers, channel names, value types, units, and expected cadence. Record the source timezone and decide how a missing or corrected value will be represented. If the source calls one field pressure and the dashboard calls it Water pressure, retain the stable source name and use an alias for the display.
Map the register to projects and sites. Sites should reflect places the team recognizes; groups can express cross-site review packages. Check logger relationships separately. A shared logger explains collection hardware, while an instrument and its variables define the measurement identity. Get these distinctions right while the scope is still small.
Prove the path with known values.
Use representative source data, not just the easiest sample row. Include the timestamp format, numeric precision, and missing-value conventions that will occur in practice. Preview parsing or catalog mappings, or submit a small API batch. Follow the resulting processing run and verify the stored instrument, channel, timestamp, and value.
Then test the calculation and review layers. Compare at least one derived value against an independently checked example, confirm the relevant time range on a dashboard, and verify access with the intended audience. If anomaly definitions are part of the workflow, test their targets and condition logic and inspect the notification configuration separately.
Plan for ordinary change.
Decide who investigates a delayed source, changes a parser, updates a calibration constant, or moves an instrument between sites. Write down how they verify the result and whom they inform. Review access and email recipients when project responsibilities change. These ordinary tasks are part of operating a monitoring program, not exceptional cleanup.
Account for complete source outages independently of data-triggered missing-signal evaluation. Also plan the end of an instrument's active life: resolve calculation dependencies, archive deliberately, and retain the context needed to interpret its history. A workflow that handles commissioning, daily operation, and retirement is easier to carry from the first work area to the rest of the job.
Common questions.
What should our first implementation include?
One representative site, a small instrument set, the real collection route, a calculation where needed, and a dashboard used by its intended reviewer. Expand after the entire path has been checked.
What can we prepare before speaking with SanSignal?
Bring a source sample, instrument register, project locations, example engineering calculations, intended reviewers, and expected data volume. These provide a concrete basis for discussing setup and scope.