How we work — end to end.

A good piping stress analysis methodology is not the output of a single software run. It is a documented, repeatable workflow that starts before modelling and continues after the report is issued. Seven steps, ASME-aligned, with a deliverable pack formatted for direct handoff.

Our seven-step methodology

Built on ASME B31.3 and B31.1, using CAESAR II for critical lines. Every decision — from critical-line screening to support selection — is explained in the final report.

Design data validation

We review P&ID, piping isometrics, line list, material specifications, and equipment data sheets for completeness. Any gaps are flagged and closed before any modelling begins. Ninety percent of rework during a piping stress analysis project comes from incomplete or inconsistent input data discovered too late.

Critical versus non-critical screening

Each line is classified as critical (requiring full CAESAR II analysis) or non-critical (suitable for manual cantilever-beam calculation). Screening criteria: pipe size > 2", design temperature above 150 °C, connection to rotating or sensitive equipment, seismic exposure, or prior incident history.

Model build in CAESAR II

Validated isometrics are rebuilt inside CAESAR II. Supports, restraints, branch connections, expansion joints, and equipment interfaces modelled with the right boundary conditions — not default assumptions. Every model peer-reviewed by a second engineer before load cases are applied.

Load case development & iteration

Sustained, thermal, occasional, and dynamic load cases are built from the operating philosophy, not templates. Iterations continue until every line is within the allowable stress limits of ASME B31.3 or B31.1 and every support sits within its manufacturer's capacity.

Support & restraint optimization

Supports are selected to manage movement and distribute loads safely. Because Softstra supplies piping hardware through South Moonsgate Sdn Bhd, we know which configurations are actually available and which are specification-only. Spring hanger and expansion joint vendor drawings reviewed before hardware leaves the supplier.

Nozzle & flange verification

Nozzle forces and moments on pumps, compressors, turbines, vessels, and exchangers verified against vendor allowables or the relevant API code (API 610, API 617). Critical flange joints checked for leakage per ASME Section VIII Div 1 Appendix 2 and PCC-1.

Report, isometric markup & handoff

Every engagement concludes with a stress report, support load table, nozzle load summary, marked-up isometric drawings, and an executive summary. Support loads formatted for direct handoff to civil and structural engineers designing the pipe racks.

Inputs we ask from the client

Deliverables

Every Softstra piping stress analysis produces the same deliverable structure, scaled to the engagement size. Each stakeholder receives a document they can act on directly.

Core deliverables

Optional add-on deliverables

Who uses each deliverable

Project engineer / EPC lead

Executive summary and stress report for code compliance sign-off and review meetings.

Civil & structural engineers

Support load table for pipe rack, sleeper, and T-support structural design.

Piping designer / draughtsman

Marked-up isometrics for support installation detailing and construction package issue.

Equipment engineer / mechanical lead

Nozzle load summary for verification against purchased equipment vendor data.

Construction / site team

Marked-up isometrics and support schedule for installation.

Commissioning / operations

Post-commissioning stress walk-down (optional) and spring hanger travel verification.

Format and handover standards

How we collaborate

Frequently Asked Questions

We use objective criteria — pipe size greater than two inches, design temperature above 150 °C, connection to rotating or sensitive equipment, seismic exposure, or a history of stress or leakage incidents. Any line meeting one or more criteria is flagged as critical.

Every model is built from validated project isometrics. Material, insulation, and boundary conditions come from project data sheets — never from default libraries.

Every model peer-reviewed by a second engineer before load cases are applied. Final report reviewed with the client's lead engineer before issue.

Yes, as standard. Native CAESAR II input files delivered at project close — enabling future revisions, what-if studies, or operational analyses to start from the verified model.

Yes. Minor revisions (moved support, changed routing) handled within the agreed scope. Significant revisions quoted separately. Deliverable pack versioned with revision history.