PoPAN: Context-Dependent Engineering & Networking
- PoPAN is a context-dependent acronym that denotes distinct models and methods across multiple engineering disciplines.
- In its official use for lifecycle engineering, PoPAN reorients the Product–Process–Resource paradigm to enable digital shadows and versatile assembly/disassembly planning.
- The term also informally refers to techniques in monocular normal estimation, Bayesian particle flow, power packet networks, and QoS routing, illustrating diverse practical applications.
PoPAN is a context-dependent label rather than a single, universally standardized acronym. In the cited arXiv literature, it most specifically denotes the Product-oriented Product–Process–Resource Asset Network, a product-centric lifecycle model intended to accompany a product as a digital shadow within the Asset Administration Shell (Strakosova et al., 1 Oct 2025). In other contexts, however, “PoPAN” is only an informal shorthand or external mapping: it is used to refer to Poppy, a polarization-based plug-and-play framework for monocular normal estimation (Kim et al., 29 Mar 2026); to Population-Aware Physics-Informed Neural Particle Flow, whose official abbreviation is PA-PINPF (Candan et al., 9 Jun 2026); to the Power Packet Network paradigm in decentralized power distribution (Baek et al., 2020); to the umbrella concept of power- and delay-aware on-demand routing instantiated by PDTORA (Jagadev et al., 2010); and to the Pop-aware packet scheduler for congestion control in ad-hoc social networks (Xia et al., 2020).
1. Terminological scope and disambiguation
A recurrent source of confusion is that the same four-letter string is not used consistently across fields. In several papers, the acronym does not appear in the original text and instead serves only as an informal shorthand supplied in secondary discussion. This is especially explicit for Poppy, PA-PINPF, the Power Packet Network interpretation, and Pop-aware; by contrast, PoPAN is the official name only in the product-lifecycle modeling paper (Kim et al., 29 Mar 2026, Candan et al., 9 Jun 2026, Baek et al., 2020, Xia et al., 2020, Strakosova et al., 1 Oct 2025).
| Research area | Expansion or mapped meaning | Status in source |
|---|---|---|
| Lifecycle engineering | Product-oriented Product–Process–Resource Asset Network | Official name |
| Monocular normal estimation | Poppy | “PoPAN” absent; informal shorthand |
| Bayesian particle transport | Population-Aware PINPF | Official acronym is PA-PINPF |
| Power distribution | Power Packet Network paradigm | “PoPAN” mapped to PPN context |
| MANET QoS routing | Power- and delay-aware on-demand routing | Specific protocol is PDTORA |
| ASNET congestion control | Pop-aware | “PoPAN” used only as alignment |
This terminological heterogeneity has substantive consequences. A reference to PoPAN may indicate a graph-based product model, a test-time optimization method for surface normals, a population-conditioned particle flow, a decentralized power-routing architecture, or a popularity-aware networking heuristic. The term therefore requires domain-specific disambiguation before any technical interpretation is possible.
2. Product-oriented Product–Process–Resource Asset Network
In the most literal and official sense, PoPAN is the Product-oriented Product–Process–Resource Asset Network, proposed as a modeling approach derived from the Product–Process–Resource paradigm but reorganized so that the product structure becomes the primary organizing principle (Strakosova et al., 1 Oct 2025). The motivation is twofold: widely adopted industrial standards are described as strong on the production phase and on process/resource descriptions, but they tend to treat the product as an object of processes rather than as the primary organizing principle; and sustainability requirements motivate explicit incorporation of end-of-life operations such as repair, remanufacturing, disassembly, and upcycling.
Formally, the model is described as a typed, directed, multigraph
with node partition
where contains product assets, process assets, and resource assets. Product assets are typed as ElementaryProduct, SubProduct, FastenerProduct, InitialProduct, and LastProduct. Edge classes encode physical continuity, structural continuity, product-to-process assignment, process-sequence precedence, and process-to-resource linkage. The endpoint attribute
carries assembly/disassembly orientation semantics; structural continuity determines blocking and precedence, whereas physical continuity constrains feasible next traversal steps.
The product orientation of PoPAN distinguishes it from classical PPR and from the original PAN. The network starts from the product’s multi-level structure, then attaches processes to product nodes, including conditional product-to-process assignments when process order diverges from structure, and finally links processes to resources through capability semantics. This allows a single network description to generate both assembly and disassembly plans. The paper explicitly contrasts this with the original PAN, which “typically captures one well-specified assembly process,” whereas PoPAN centers on the product structure and can generate multiple assembly and disassembly plans from one network description (Strakosova et al., 1 Oct 2025).
A central application context is lifecycle integration through the Asset Administration Shell. PoPAN is intended to accompany the product during the entire life cycle as a digital shadow encapsulated within the product’s AAS. The mapping described in the paper includes submodels such as ProductStructure, ProcessPlan, ResourceCapabilities, EOLStrategy, and QualityAndTesting. State variables are given for product assembly state, process execution state, and resource availability:
- ,
- ,
- .
For interoperability, the model is serialized in AutomationML (IEC 62714). The paper specifies use of CAEX topology and semantics through InterfaceClassLib, RoleClassLib, SystemUnitClassLib, and InstanceHierarchy. In particular, EdgeVertexInterface exposes attributes such as Direction and Arrow, while roles such as Product, Process, Resource, and Edge define semantic classes. A noted limitation is the lack of a “SubModelElement/Entity” in the AutomationML library to perfectly mirror AAS structures during transformation.
The demonstrated use case is EV battery disassembly, specifically a BMW i3 battery in a robotic testbed with KUKA manipulators, supporting remanufacturing for stationary battery applications (Strakosova et al., 1 Oct 2025). The example includes products such as lid, battery box, bolts, modules, and busbars; processes such as manipulation and screwing; and resources such as robot stations and electric screwdrivers. The traversal follows FullArrow orientations for disassembly, resolves conditional product-to-process edges via process connectivity, and binds resources through capability matching. The paper argues that this unifies manufacturing and end-of-life operations in one network and enables feedback from end-of-life data into engineering.
3. Polarization-based plug-and-play normal estimation
In computer vision, “PoPAN” is not an official method name. The relevant paper introduces Poppy: Polarization-based Plug-and-Play Guidance for Enhancing Monocular Normal Estimation, and explicitly states that the acronym PoPAN does not appear in the paper; if used, it refers informally to the same approach rather than to a distinct algorithm (Kim et al., 29 Mar 2026).
Poppy addresses monocular surface normal estimation on reflective, textureless, and dark surfaces, where RGB-only estimators are often ambiguous. Its key premise is that single-shot linear polarization measurements provide a physics-based complement to RGB cues. From the four analyzer images , the method computes observed Stokes components
0
The framework uses 1 as the RGB input 2 for a frozen differentiable monocular normal backbone 3.
The method introduces exactly three learnable, per-pixel test-time variables:
- 4, an image offset added to the RGB input;
- 5, a normal offset added after the backbone output;
- 6, a specular radiance map.
At iteration 7, the backbone produces
8
and the final unit normal is
9
A differentiable polarization renderer 0 converts the refined normals and specular radiance into predicted Stokes components. The optimization target is the masked 1 Stokes loss
2
The schedule is staged: for 3, only 4 and 5 are updated; for 6, 7 is activated for fine-scale refinement. Optimization uses Adam for 100 steps.
The framework is explicitly plug-and-play across three backbone families: Marigold for diffusion, Lotus-v2 for flow, and MoGe-2 for feed-forward inference. All weights remain frozen. The paper reports mean angular error reductions of 23–26% on synthetic data and 6–16% on real data, with synthetic MAE changes of 20.99 → 15.60 for Marigold, 16.52 → 12.26 for Lotus-v2, and 14.13 → 10.89 for MoGe-2, and real-data MAE changes of 18.18 → 15.28, 14.68 → 12.65, and 13.10 → 12.26, respectively (Kim et al., 29 Mar 2026). Threshold accuracy gains are also reported: Real Acc11.25: +7–31% absolute and Synthetic Acc11.25: +37–87% absolute.
The paper emphasizes that the approach is training-free but not instantaneous. At 768×768 and 100 optimization steps, reported runtime is approximately 57 s for MoGe-2, 99 s for Marigold, and 173 s for Lotus-v2, with peak memory usage of 12.97 GB, 35.13 GB, and 66.64 GB. Limitations include intrinsic AoLP ambiguities, simplified dielectric Fresnel modeling with scalar refractive index, orthographic assumptions unless FoV is modeled, decomposition difficulty for mixed reflectance, and failure cases under severe perspective distortion, extreme noise, highly glossy or complex BRDFs, and near-zero 8 regions (Kim et al., 29 Mar 2026).
4. Population-aware physics-informed neural particle flow
In Bayesian inference, the relevant method is Population-Aware Physics-Informed Neural Particle Flow, and the paper states that the authors’ chosen and official acronym is PA-PINPF, not PoPAN (Candan et al., 9 Jun 2026). If “PoPAN” is used in this context, it is therefore a shorthand for PA-PINPF rather than a separate method.
The problem setting is Bayesian update from prior 9 and likelihood 0 to posterior
1
The method adopts the particle-flow view with pseudo-time 2 and homotopy family
3
so that 4 is the prior and 5 is the posterior. Particles evolve by the deterministic ODE
6
under a continuity-equation constraint.
The novelty relative to standard PINPF is the addition of a permutation-invariant population encoder. Standard PINPF processes particles independently using local features
7
whereas PA-PINPF augments each particle update with a Deep Sets summary of the entire particle set:
8
Two variants are analyzed. PA-PINPF-State pools particle states 9, while PA-PINPF-Feature pools full physics-informed feature vectors 0. The paper’s interpretation is that feature-population encoding captures not only particle-cloud geometry but also “population-level Bayesian transport geometry” (Candan et al., 9 Jun 2026).
Training remains unsupervised and physics-informed: no ground-truth posterior samples are required. The residual objective enforces the Bayes-flow PDE, with divergence computed through automatic differentiation. The reported architecture uses a velocity MLP with 6 hidden layers, 64 units each, and SiLU activations, a context vector dimension 1, mean pooling, AdamW, 6000 epochs, 1000 training tasks, batch size 64, 2 training particles, and 3 inference particles (Candan et al., 9 Jun 2026).
Empirically, the method is evaluated on Range2D and time-difference-of-arrival (TDOA) posterior transport. On the Range2D family, the paper reports for PINPF versus PA-PINPF-State versus PA-PINPF-Feature:
- ED: 4, 5, 6;
- SWD: 7, 8, 9.
On TDOA, the corresponding ED values are 0, 1, and 2, while SWD becomes 3, 4, and 5 (Candan et al., 9 Jun 2026). The paper summarizes these gains as roughly 78.2% ED reduction and 47.8% SWD reduction on Range2D, and about 86% ED and 45% SWD reductions on TDOA for PA-PINPF-Feature relative to PINPF, with an overhead of about 9%–14%. Limitations include finite-particle bias and variance in expectation approximation, sensitivity to encoder design in higher dimensions, and persistent challenges from divergence estimation and ODE stiffness in very high-dimensional spaces.
5. Consensus-based power packet distribution
In power systems, PoPAN is mapped to the Power Packet Network (PPN) paradigm described in “Decentralized Algorithms for Consensus-Based Power Packet Distribution” (Baek et al., 2020). The paper does not explicitly define “PoPAN,” but the mapping treats it as the decentralized, communication-driven, store-and-forward power packet distribution network regulated by local consensus dynamics and a lightweight handshake protocol.
A power packet is a pulsed DC sequence that carries both an information tag and a power payload. The tag contains a header and footer, while the payload is the physical energy transferred during the packet’s on interval. In the reported simulations, the packet parameters are:
- bit time: 6,
- bit length: 100 bits,
- packet duration: 7,
- information tag: 10 bits,
- payload duty: 90%.
Routers implement store-and-forward using switches, gate drivers, controllers, local storage, and photocouplers. Packets are buffered by storage elements and forwarded after header parsing and payload reception. This produces quantized energy flow and relaxes strict real-time supply-demand balance. The network itself is modeled as a graph 8, with edge weights 9 when connected and node capacitances 0. The consensus dynamics are written in agent form as
1
and in vector form as
2
The discrete update is
3
with stability for connected 4 under
5
The physical interpretation is 6, the storage-node voltage, and voltage balancing acts as a proxy for supply/demand equilibrium.
The communication protocol is local and lightweight: query, acc, start, and end. In bottom-up mode, demand initiates a query; in top-down mode, suppliers begin with acc messages to eligible neighbors. The paper reports that top-down tends to increase throughput, while bottom-up adds handshake latency and larger fluctuations. A local evaluation function is defined as
7
with
8
This drives the event-triggered routing logic and biased flow behavior.
Simulation uses two topologies: a 1D chain with five storage nodes and a triangular mesh with multiple downstream paths. Common parameters include source voltage 9 V, storage capacitances 0, switching resistance 1 1, load resistance 50 2, and mode transition time 3, with ten runs per method and random initial voltages in 4 V (Baek et al., 2020). The reported findings are that bottom-up exhibits larger fluctuations and lower downstream voltages than top-down, that nodes with higher inflow degree exhibit higher voltages in the triangular mesh, and that mixed control induces protocol-level bias such as suppressed cross-method paths. The paper presents this as evidence of structure-independent operation, scalable decentralized distribution, and controllable biased power flows.
6. QoS-aware and popularity-aware networking usages
In communication networking, PoPAN is used in two additional, unrelated senses: as a label for power- and delay-aware on-demand MANET routing, and as a label for popularity-aware packet scheduling in ad-hoc social networks. In neither case is PoPAN the canonical name of the proposed protocol (Jagadev et al., 2010, Xia et al., 2020).
The MANET paper proposes PDTORA, a Power and Delay aware Temporally Ordered Routing Algorithm built on TORA (Jagadev et al., 2010). The term PoPAN accurately labels the umbrella concept of power- and delay-aware on-demand routing, but the implemented protocol is PDTORA. The QoS goal is simultaneous enforcement of a maximum end-to-end delay bound and a minimum residual power threshold at every node on the route. Delay is treated as an additive metric, while power is concave. Query packets carry fields of the form QRY(5), illustrated in the paper by QRY(src=1, des=7, 0.2, 50ms). At each intermediate node, the query is dropped if residual power falls below the threshold or if the remaining delay budget after subtracting local Node Traverse Time (NTT) becomes infeasible. Route maintenance remains TORA-style through height-based DAG updates, localized link reversal, and clear messages under partition.
The evaluation uses ns-2, IEEE 802.11 WaveLAN at 2 Mbps, 50 mobile nodes, a 670 m × 670 m area, 250 m radio range, Random Waypoint mobility, delay 6 ms, minimum power 7, and 20 joules initial energy per node. Relative to TORA, PDTORA is reported to achieve approximately 3% higher PDR at high mobility, 15% higher PDR at 10 m/s, 23% at 20 m/s, approximately 60% improvement in end-to-end delay, first node death at 65 s rather than 25 s, and at 100 s only 6 dead nodes rather than 41 (Jagadev et al., 2010). The interpretation given is that low-power nodes are pruned during discovery and unstable or overly long routes are excluded by the delay budget.
The ASNET paper proposes Pop-aware, a user-popularity-based packet scheduler for congestion control (Xia et al., 2020). Here again, “PoPAN” is an alignment term rather than the paper’s own name. The algorithm operates at a shared intermediate node and uses degree centrality as the popularity metric:
8
Congestion is monitored through the load indicator
9
and scheduling is triggered when this reaches half of the queue capacity; otherwise FIFO is used. The scheduler admits the top 0 flows satisfying the schedulability condition
1
and under queue saturation it may replace the least-popular admitted flow if the new flow has larger degree centrality and feasible normalized rate.
The reported OPNET configuration uses 50 nodes, a 1000 m × 1000 m area, 250 m radio range, IEEE 802.11, 2 Mb/s channel capacity, static routing, 64-packet scheduler buffers, CBR traffic, 512-byte packets, and 800 s simulations. Compared with CaSMA, S-R-1, and wGPD, Pop-aware reports lower control overhead, with high-connection maxima of 19, 22, 29, and 34 2 packets respectively; throughput gains of 9.1%, 12.1%, and 16.67% relative to the three baselines; loss-rate reductions of 0.5%, 0.7%, and 1.1%; and maximum average delay about 13.4%, 15.5%, and 22.82% lower than wGPD, CaSMA, and S-R-1, respectively (Xia et al., 2020). The paper also reports 63.5% packet delivery rate with scheduling versus 41% without, and 4500 ms average delay with scheduling versus 8000 ms without at 50 connections. Its fairness mechanism is described qualitatively through active service adjustment and throughput normalization rather than by a reported Jain-style fairness index.
Across these networking usages, the only stable conclusion is terminological: PoPAN does not name a single networking protocol. It may denote a power-aware routing concept, a popularity-aware scheduler, or a mapped description of a power packet network, depending on the cited source.
