Appearance
What Does a Change Affect?
Before you change a pump or retag an instrument, ask the drawing what else depends on it. The answer is computed from your own data — wiring, loops, I/O, datasheets, BoQ lines, simulation units, HAZOP nodes, validation findings — not from links somebody remembered to create.
Where it is
Select one equipment item or instrument, open the properties panel's Engineering tab, and look for the section headed "What does a change affect?".
If the panel shows "Select a single equipment or instrument to edit engineering properties.", the selection is not one the Engineering tab works on — select a single symbol.
With the element selected, press Check; the dependants are listed in groups under the button, each group headed by how many items it holds.
Using it
| Control / state | What happens |
|---|---|
| Check | Works out the dependants. Nothing is computed until you ask. |
| Refresh | The same button after a result — recomputes it. |
| Save the drawing to see what depends on this element. | Shown, and the button disabled, while the drawing has never been saved. |
| Tracing dependants… | In progress. |
| This element is not in the saved drawing yet — save, then check again. | The element exists on your canvas but not in the last save. |
| Nothing depends on this element yet. | The element is saved and genuinely has no dependants. |
| Could not work out the impact of this element. | The request failed; press Check again. |
Changing the selection clears the previous answer, so you are never looking at the last element's result.
What it reports
Each group carries a count badge and a one-line consequence — what a change to this element means for that group. Groups with nothing in them are left out entirely, so a short answer is a real answer.
| Group | What is in it | The consequence line |
|---|---|---|
| Connected on the drawing | Every element wired directly to this one | Check the connection still makes sense: line size, service and direction. |
| Loop nnn | The other instruments sharing this instrument's ISA loop number | Instruments in the same loop — ranges, signals and setpoints must stay consistent. |
| I/O list | The I/O points this element produces, with their signal and source | The I/O list is rebuilt from the saved drawing; re-issue it if these points change. |
| Control philosophy | Loops and operating-mode entries that describe this element | Sections that describe this element — regenerate the skeleton and review the text. |
| Datasheets | Datasheets held against this element, by family, with revision | Regenerate: the revision moves only if a value changes. |
| Bill of quantities | Lines in the drawing's latest BoQ matching this element | The BoQ regenerates when the drawing is saved; manual overrides are kept and flagged. |
| Simulation | Simulation units compiled from this element, with when they were compiled | Recompile the drawing into the simulation and re-run: the unit's inputs may have changed. |
| HAZOP | HAZOP nodes that reference this element, with the study name | A design change on a studied node may need the node revisited. |
| Open validation findings | Findings recorded against this element by the last validation run | From the last validation run — re-validate after the change. |
Where the two things are matched by tag rather than by element id (BoQ lines, simulation units), an element with no tag will show fewer dependants than it really has. Tag your elements.
Renaming a tag
A tag is a label on the element; the element itself is what everything else is tied to. When you type a new tag into the properties panel (or a saved drawing is reconciled with the project tag register and an element's tag has changed), the new tag is written straight into the places that keep a copy of it. You do not have to regenerate anything to see it.
| Where | What changes | What stays the same |
|---|---|---|
| Bill of quantities | The tag on every line for this element. For a pipe line, the tag at the start of its description too. | Quantities, costs and manual overrides. An overridden line keeps its quantity. |
| Datasheets | The tag on each datasheet for this element. | The datasheet's contents. It now shows Out of date; press Regenerate when you are ready. |
| HAZOP | The node tag of each HAZOP node that references this element. | Deviations, causes and actions. |
| I/O list, control philosophy | Nothing is stored: both are built from the drawing each time you open them, so they show the new tag as soon as the drawing has it. | — |
| Audit log | A tag.renamed entry with the old tag, the new tag and the element. | — |
| Change history | A tag-change entry for the project, e.g. "Tag P-101 renamed to P-102 on drawing …: BoM 2 lines, 1 datasheet, 1 HAZOP node". | — |
When the rename is done, a short message lists what was updated, e.g. "Tag renamed P-101 → P-102 — updated in BoM (2 lines), 1 datasheet; I/O list and Control philosophy follow the drawing."
Some things to know:
- Only this element's records change. If another element's BoQ line, datasheet or HAZOP node happens to show the same tag text, it is left alone.
- Older records with no element link are matched on the old tag text. This only happens if no other element still holds that tag.
- The rename is all or nothing. Either the register and every copy are updated together, or none of them are. Saving the same tag again does nothing more.
- You cannot rename to a tag that is already in use. If another element in the project holds the tag, the rename is refused and the old tag is put back.
Renaming many tags at once (renumber, find and replace)
Find & Replace Tags (Ctrl+F, or the toolbar) renames many tags in one go: the Replace tab rewrites tags that match a pattern, and the Renumber tab gives the equipment in the drawing (or your selection) a new sequence such as V-1001, V-1002, … in top-to-bottom, left-to-right or radial order.
Press Preview to see the proposed tags, then Replace All or Apply. Before anything changes, a second window, What this rename affects, checks the whole change with the project tag register. It shows:
- one row per element, old tag → new tag;
- how many BoM lines, datasheets, HAZOP nodes and I/O points each rename reaches, with the totals above the list;
- any conflict: a new tag that another element in the project already holds, two elements in the change that would end up with the same tag, or a tag another element on this drawing already shows.
A conflict blocks the change. Adjust the renumber or replace settings, preview again, and the window opens with a fresh check. Swapping two tags (P-101 ↔ P-102), or shifting a run of numbers up by one, is not a conflict: each tag's holder is moving away from it in the same change.
Press Rename N tags to confirm. Every rename and every copy it updates (the table above) is saved together, in one step: either all of the renames happen or none do. The drawing then shows the new tags, and a message sums up what was updated, e.g. "Renamed 4 tags — updated in BoM (3 lines), 2 datasheets; I/O list and Control philosophy follow the drawing." The audit log and the change history get one entry per renamed element.
If another user takes one of the new tags between your preview and your confirm, nothing is changed. The window marks the conflict so you can adjust and try again.
When the tag register cannot be reached (you are offline, or the server is down), the window says so and the button reads Rename N tags on this drawing only. Confirming changes the tags on this drawing only. The BoM, datasheets and HAZOP keep the old tags until the drawing is reconciled with the register.
What this does not do
- A datasheet tells you when it is out of date. If the element's tag, symbol or properties change after a datasheet was generated, or the element is removed, the Datasheet tab of the BoM item shows an Out of date badge (hover for the reason). Nothing is regenerated for you, so your manual datasheet entries are never overwritten; press Regenerate to refresh it and clear the badge.
- It shows dependants; it does not regenerate them. Pressing Check changes nothing. No datasheet is reissued, no BoQ is rebuilt, no validation is re-run, no simulation is recompiled. The consequence lines tell you what to do — you still do it, from the places that do it: I/O list, Control philosophy, the BoM page, Tools → Validate Drawing, "Simulate this drawing".
- It is not a change-approval step. It does not block the edit, warn on save, or record that you looked.
- It reads the last save, not the canvas. Make the save first if you want the current picture; the section says so when the element is not in the save yet.
- It does not predict the effect of a change. It answers "what is attached to this?", not "what will break if I halve the flow?". No values are recalculated.
- Only the latest BoQ version is searched. Lines in older BoQ versions of the same drawing are not listed.
- Validation findings are the stored ones. They come from whenever validation last ran, which may be older than your last edit.
- HAZOP matching needs a GUID element id. Nodes are matched on the drawing node id read as a GUID; an element whose id is not GUID-shaped (older drawings, some imports) will never show a HAZOP group even if a study references it by tag.
- Simulation units come from compile records. A drawing that has never been compiled into a simulation shows no simulation group.
- The control philosophy group is computed, not read from an issued document. It is derived from the same builder as the skeleton PDF; it does not know about a Word document somebody issued.
See also
- I/O List — the list the I/O points group refers to
- Control Philosophy — the skeleton the control-philosophy group refers to
- Server-Side Validation — where the findings come from