PATERN Framework Overview

• PATERN is a framework that uses domain-specific patterns to capture and verify complex functional and performance requirements in software-intensive systems.
• It formalizes pattern composition through algebraic operators, enabling structured, reusable, and verifiable design models.
• The framework also applies dual-encoder strategies for terrain-aware robot navigation, ensuring human-preferred path planning via automated quality assurance.

The PATERN framework encompasses three distinct research efforts, covering: (1) pattern-based, domain-specific requirements engineering for software-intensive systems, (2) formal algebraic modeling of software design pattern composition, and (3) preference extrapolation for terrain-aware robot navigation. Each instantiation shares a commitment to pattern-based abstraction, but addresses unique technical domains and exhibits specific formal properties, workflows, and application scenarios (Chuprina et al., 2024, 0802.3784, Karnan et al., 2023).

1. Pattern-Based Domain-Specific Requirements Engineering

Originating in requirements engineering research, PATERN (Pattern-based Domain-Specific Requirements Engineering Approach) targets two of the most severe industry problems: “weak domain knowledge” and “underspecified requirements” as evidenced by the NaPiRE study (Chuprina et al., 2024). Traditional requirement patterns such as EARS and boilerplate methods are domain-independent and insufficiently capture complex, domain-tailored semantics, such as those needed for unmanned aerial vehicle (UAV) flight controllers. PATERN’s core objective is to unify the simplicity and reusability of patterns with domain-specific expressiveness, guiding precise specification of both functional and performance requirements.

PATERN achieves this by:

• Embedding domain concepts (e.g., "overshoot," "horizontal deviation") as explicit, first-class pattern parameters.
• Providing structured graphical (sketch-based) and tabular representations.
• Enabling semi-automated quality checks (consistency, completeness, conformance to physical domain laws).
• Bridging requirements and downstream system verification (including defect-based, simulation-driven testing).

2. Architectural Layers and Workflow

The PATERN framework in requirements engineering consists of three primary process layers:

Layer	Activities	Outputs
Domain Knowledge Analysis	Collect domain artefacts, elicit recurring requirement "shapes" from experts	Recurring requirement forms
Pattern Definition & Instantiation	Define meta-model (DSRCollection, DSRPattern, DSRElement); create figures/tables; parameterize for each project	Instantiated domain-specific patterns
Tool-Supported Verification & QA	Static quality checks (syntactic/semantic), defect-based testing via model simulation, defect metric visualization	Prioritized test scenarios & reports

This architecture propagates domain knowledge seamlessly from high-level requirements capture through automated verification and system validation.

3. Formalization of Domain-Specific Requirement Patterns

Each DSRPattern is formulated in a semi-formal syntax. The skeleton representation for a pattern $P$ includes:

• FigureElement: Sketch of maneuver containing named variables.
• TableInitFinal: (param, min, max, unit) for initial/final system states.
• TableHorizDev: (time, max horizontal error, unit).
• TableAltDev: (time, max altitude error, unit).

Key parameters:

• $Θ, Ψ, Φ \in \mathbb{R}$: angular parameters.
• $h \in \mathbb{R}$: altitude.
• $Δh_{ov}(t), Δ(x,y)(t) \in \mathbb{R}$: time-dependent error functions.

Example formal constraints:

$$0 \leq Θ_{\text{ini}} \leq 20°,\quad 0 \leq Ψ_{\text{ini}} \leq 360°,\quad h_{\text{final}} \in [2,3]\,\text{m}$$

and, $\forall t$,

$$Δ(x,y)(t) \leq Δ_{max}^{horiz}(t),\quad Δh_{ov}(t) \leq Δ_{max}^{vert}(t)$$

4. Automated Quality Assurance and Defect-Based Testing

PATERN integrates automated static checks to enforce the following defect criteria:

• Omission/Completeness: missing tabular entries.
• Contradiction/Consistency: overlapping or inverted parameter ranges.
• Incorrect Domain Laws/Adequacy: values outside feasible/physical boundaries (e.g., $Θ > 90°$).
• Imprecision/Unambiguity: open intervals or missing units in numerical ranges.

Tool support allows direct mapping from pattern parameters to constraint checks, eschewing free-text NLP. For verification, the defect-based testing regime partitions input spaces (such as $(Θ, Ψ, h$)), generates random scenarios within each partition, simulates system response, and computes a defect metric:

$$dfb(S_i) = \begin{cases} \infty, & \max_t Δ(x,y)(t) > Δ_{max}^{horiz} \ \dfrac{1}{Δ_{max}^{horiz} - \max_t Δ(x,y)(t)}, & \text{otherwise} \end{cases}$$

Risk-hot partitions are identified for targeted verification.

5. Pattern Algebra and Composition: Formal Model

The POAD Theory version of PATERN views patterns as endomorphisms on a normed concept space $\mathcal{C}$, with formal composition operators (0802.3784):

• Stringing-together ($+$): $P + Q$ combines roles/classes; commutative, associative, subadditive in norm.
• Overlapping (scalar multiplication): $\alpha P$, with real scalar $\alpha$ indicating degree of role/class merging, and can amplify complexity.

These operations imbue the set of patterns $\mathcal{P}$ with vector space structure (normed algebra), enabling formal analysis of composition, complexity growth, and correctness. For example, correctness can be assessed by bounding the norm difference between a composite and the specification, i.e., $||P_1+\cdots+P_n - Q|| \leq \varepsilon$.

6. Preference Extrapolation for Terrain-Aware Robot Navigation

A distinct instantiation of PATERN addresses operator preference-aligned path planning, with the full system described in "Wait, That Feels Familiar" (Karnan et al., 2023). Here,

• A mobile robot observes both visual data ($O_t \in \mathbb{R}^{64 \times 64 \times 3}$, bird’s-eye RGB) and proprioceptive data ($\tau_t \in \mathbb{R}^{D_{pro}}$), the latter including inertial, joint, and tactile features.
• PATERN employs dual encoders: $f_{vis}$ (CNN) for visual, $f_{pro}$ (MLP) for proprioceptive, both projecting to $\mathbb{R}^8$ embeddings.
• Preference scores $u_{vis}, u_{pro}$ are learned, with visual-proprioceptive disagreement used as an OOD trigger.
• For previously unseen terrains, clusters are formed in proprioceptive embedding space; nearest-neighbor lookup to known terrains transfers operator-labeled preference to novel clusters.
• After adaptation, augmented examples are used to re-train $f_{vis}$ and $u_{vis}$ ("patern⁺").
• Path planning incorporates the extrapolated cost $c_P(s) = \exp(-u_{vis}(f_{vis}(O_s)))$ into sampling- or graph-based planners.

Experimental results demonstrate that patern⁺ closely matches human-preferred navigation in novel environments, both by trajectory alignment (mean Hausdorff error $1{-}1.1$ m) and terrain preference (over 98% alignment), all achieved without manual relabeling of new terrain (Karnan et al., 2023).

7. Limitations, Best Practices, and Research Outlook

Current coverage in requirements engineering is limited to performance and mode-transition requirements, with informal syntax and semantics. Broader empirical validation and extension to other non-functional property domains (safety, security) remain outstanding tasks. Best practices include early expert involvement for pattern elicitation and automation of static QA checks via explicit domain law encoding (Chuprina et al., 2024).

In algebraic pattern composition, the formalism offers fine control over complexity but does not address empirical domain instantiation or semantic mapping to executable artifacts (0802.3784).

In preference extrapolation, the nearest-neighbor mechanism and dual-encoder architecture are effective for surface types and lighting but rely on embodied similarity between proprioceptive signatures of seen and novel terrains. A plausible implication is that further generalization may require more sophisticated relational modeling or active querying strategies.

Future research across all PATERN variants seeks tighter integration with formal verification (e.g., SMT solving), broader domain application (railway, automotive, safety-critical systems), and systematic user studies to quantify productivity and assurance gains.