Proposal: P&ID (piping and instrumentation diagrams) in QElectroTech

[Opus-id]

Hello everyone,

I'm Opus on the forum, a designer in water treatment (drinking water production plants, wastewater treatment plants) with about 25 years of experience. Following @scorpio810's suggestion on the forum, I'm moving here the proposal I posted on October 11 in the thread I opened in 2016 (https://qelectrotech.org/forum/viewtopic.php?id=938&p=2). My motivations are in this comment. P&ID was also mentioned in #1203, and #1267 discusses a per-project standard setting.

I have forked the repository, compiled QET on WSL2/Debian and created a working branch, with the help of Claude (I'm not a developer). I plan to contribute through small, separate PRs. Nothing will be submitted before 0.200.2.

What a P&ID needs

• Data-carrying symbols (pumps, valves, tanks, instruments), with terminals named as nozzles (N1, N2…) and a "DEXPI class" attribute. The symbols are inspired by ISO 10628-2, without strict compliance.
• Typed piping: DN, material, fluid, flow. There is no notion of wire, cable or potential.
• A line list, synchronized with a spreadsheet by external scripts. QET itself is not changed for this, and the scripts never modify the original file. Spreadsheet round-trips were already requested in the same forum thread in 2018.

Out of scope: calculations, flow direction, instrument loops, strict ISO 10628-2 or DEXPI compliance.

Proposed design

• A pipe class separate from Conductor. It keeps only the orthogonal routing.
• Pipes stored in a separate <pipes> XML block, which older versions ignore.
• A "P&ID" project type that forbids electrical conductors. Existing projects stay electrical. Whether pipes should be forbidden in electrical projects is up to the maintainers.

Questions

1. Should the project type be a separate attribute from the standard setting discussed in Proposal: a roadmap to make IEC-standard drawings the easy path in QElectroTech #1267? How should it be stored in the .qet file?
2. Is a separate <pipes> block acceptable?
3. Which architecture pitfalls should I avoid? @Joshua-cla, @arummler, your opinion would be very valuable.
4. Terminals currently only accept Conductor objects. Should pipes get their own terminal type, or should Terminal be generalized?

Thanks for your feedback.