03 — Integration
Condition Monitoring is a member of the Work & Supply network (message protocol v1) with the network domain condition.
Its contract is schema/condition_monitoring.integration.dsl (authoring spec v1.5), generated with
python -m codegen.cli integration condition_monitoring --network work_supply; the handlers are in integration/handlers.py.
The whole network is in networks/work_supply/NETWORK_MAP.md.
What it owns
| Network entity | Model | Business reference |
|---|---|---|
condition.result |
Result | result_number (RS-{sequence:05}) |
condition.alert |
ConditionAlert | alert_number (CA-{sequence:05}) |
Messages
| Kind | Message | What |
|---|---|---|
| publishes | condition.elevated_reading / condition.urgent_reading |
an alert was raised: the unit, SMCS code, SMU, parameter, finding |
| publishes | condition.pattern_detected |
a wear pattern reached possible or confirmed: the unit, SMCS code, pattern, SMU, wording and the corrective template number |
| publishes | condition.alert_resolved |
the Work order for an alert closed |
| consumes | asset.component_installed / asset.component_removed |
something changed at this unit and SMCS code: the trend restarts (which component is not kept) |
| consumes | work.work_order_created |
the order Work raised for an alert (its cause is the alert's command) |
| consumes | work.work_closed |
resolve the alerts of that order; with oil_changed, restart the trend for the unit and SMCS code |
| consumes | classification.*_reference_changed, asset.asset_group_reference_changed, asset.asset_reference_changed |
readable references stay current |
| accepts | condition.record_result |
a result with its values in one call (idempotent on the lab's result id) |
| accepts | condition.acknowledge_alert, condition.recalculate_standards, condition.recalculate_reliability |
the last reads the Register's component history and Lifecycle's exposure |
| answers | condition.series_state, condition.pattern_status, condition.result_history |
read-only |
| sends | work.create_work_order |
the command that an urgent alert makes (accepted by Work from this application) |
| reads | lifecycle.usage_at, asset.group_membership, asset.profile, asset.search_components, asset.component_history, lifecycle.component_exposure |
synchronous, read-only lookups |
How an urgent alert reaches Work
The handler queues the Work Management command work.create_work_order in the outbox, in the same transaction, with the unit,
a title, the alert as source_entity_type = condition.alert / source_entity_cid, and the route's Work template
(work_template_ref, from alert_routing.yaml); no work type is sent (Work takes it from the template). The command's
message id is ALERT-<alert cid>, so the work.work_order_created event Work raises while handling it names it as its cause;
that is how the alert learns its work order.
References
classification.smcs / classification.modifier (pickers), asset.asset, asset.asset_group (pickers),
work.maintenance_template (a pattern's corrective template, picked with work.search_maintenance_templates) and
work.work_order; the Work template of a route is a template code in alert_routing.yaml, found in Work with
work.search_maintenance_templates.