QA Piping Systems FluidFlow
QA Piping Systems FluidFlow
QA Piping Systems FluidFlow
Table of Contents
Part I Introduction
1 Software Requirements
...................................................................................................................................
and Specification
4
2 Overall Design
...................................................................................................................................
and Architecture
5
3 Model Development
................................................................................................................................... 5
4 Algorithm ...................................................................................................................................
Development
6
5 Coding
................................................................................................................................... 7
6 Integration................................................................................................................................... 7
7 Integration...................................................................................................................................
Testing
7
8 Data
................................................................................................................................... 8
9 Installation
................................................................................................................................... 8
10 User Operation
................................................................................................................................... 8
11 Maintenance
................................................................................................................................... 9
1 Standards...................................................................................................................................
Used
9
2 Liquid Pressure
...................................................................................................................................
Loss Calculations
10
3 Gas Pressure
...................................................................................................................................
Loss Calculations
11
4 Non Newtonian
...................................................................................................................................
Fluid Pressure Loss Calculations
11
5 Settling Slurry
...................................................................................................................................
Pressure Loss Calculations
12
6 Two Phase
...................................................................................................................................
Pressure Loss Calculations
12
7 Physical ...................................................................................................................................
Property Estimation Methods
13
Introduction
Introduction
This document is an attempt to explain the procedures, processes and efforts made
by Flite Software NI Ltd, the developers of "Piping Systems FluidFlow", to minimise
the occurrence and impact of errors in the end user operation and functionality of our
software.
To be effective, a Software Quality Assurance policy needs to be an integral part of
the entire life cycle of our software application. In addition, our Quality Assurance
policy is continually evolving as we find more effective ways of developing and
validating our software. This document provides an overview of where we are today
and how the "Quality Assurance focus" is integrated into our business and life cycle
processes.
The life cycle of our product "Piping Systems FluidFlow" has many steps. Each step
has its own distinct validation requirements.
In this context validation is defined as establishing, by objective evidence, that all
software requirements have been implemented correctly and fully.
In addition to validating each process step the integrated product needs also to be
validated.
The remainder of this document is therefore split into 2 logical chapters:
1. A description of the individual steps in our product life cycle.
2. An overview of the main standards and methods used in our calculation
procedures.
Development Steps:
Software Requirements and Specification
Overall Design and Architecture
Model Development
Algorithm Development
Coding
Integration
2.1
Practical
Safe
Efficient
Reliable
To achieve the above end user design goals, the software must be easy to use,
comprehensive, robust, and of validated high quality using the latest, appropriate,
calculation techniques and prediction methods.
Our product does not stop there, it is also important that the engineer can
communicate their designs for peer review and directly to customers.
This document does not discuss further, design and specification of the user interface,
or other functional input/output specifications but focuses on the main engineering
specifications.
The product is designed to calculate phase state, pressures, pressure losses,
temperatures and flows for any fluid(s) flowing in a piping system. The system must
be at steady state conditions.
Phase states handled by the software can be liquid, gas, non-Newtonian, solid-liquid
two phase slurries or liquid-gas two phase. There are many calculation methods,
available in the literature that can be used for the prediction of energy losses in
flowing systems and for the prediction of physical and transport properties that are
needed to support these calculations.
Unfortunately there are no agreed universal standards for the method to be used in
each specific case. Where internationally recognised design and calculation standards
or methods exist FluidFlow uses the appropriate standard. Standards and calculation
methods used are detailed in Standards chapter.
Where standards do not exist regarding a calculation method or physical property
prediction FluidFlow always offers alternative methods to the end user.
It is the responsibility of the engineer/end user to exercise due care and diligence by
selecting an appropriate method and to interpret the results with knowledge of the
simulation limitations.
2.2
2.3
Model Development
Our software uses many mathematical models to simulate physical phenomena.
These models rely on established laws of physics or on empirical relationships. Often
the models are only approximate in nature or have a limited validity range.
Validation of these models includes dynamic, static and formal techniques.
Dynamic techniques demonstrate the software's behaviour in response to selected
inputs and conditions. We use prototyping to verify the hardware response to
2.4
Algorithm Development
An algorithm is a logical procedure for solving a models mathematical equations. It
takes input data and transforms it into output predicted by the model. We use logic
and data flow diagrams to illustrate and define the logical sequence of events.
Algorithms serve as a bridge between the model and the code, where the program
code follows the sequence of activities required by the algorithm. Over the last 20
years we have established well tested, efficient and tried algorithms for commonly
needed tasks.
Where possible these algorithms have been encapsulated. An example of a common
task when solving mathematical models is the need for a solution to an explicit
equation.
Explicit equations cannot be solved directly but require an iterative solution.
Specifically, we might consider the calculation of friction factor via the ColebrookWhite equation. By using an encapsulated, validated, generic algorithm such as
Newton-Raphson, Successive Approximation or Secant we eliminate the need to write
specific code for the solution of the Colebrook-White equation.
Algorithm analysis is carried out to ensure that the criteria of accuracy, timing,
stability and size requirements are met.
Consistency checks are made where appropriate. For example, consider the adiabatic
flow of a compressible fluid in a pipe. To be consistent we should be able to take any
of the Fanno flow property relationships and ensure that these conditions are
consistent from low flows right up to the speed of sound.
2.5
Coding
Coding is the language used to communicate the algorithm to the computer. A
compiler converts this code to an executable file. Our application produces one
executable file without the need for associated DLL's. This streamlines our
maintenance and updates procedure.
Where possible we purchase "best of breed" toolkits, this avoids wasting time "reinventing the wheel" and ensures an up to date look and feel to the software.
The compiler and integrated development environment we use provides excellent
debugging features which helps to validate new code and also speeds up the bug
finding and elimination process.
We operate a coding style using strict internal guidelines. This means that code
written by one programmer is always consistent in its layout, structure and well
commented. This allows for easier cross checking, helps cross-fertilise ideas and can
be quickly understood by all team members.
2.6
Integration
Our software is developed by a closely knit, experienced team of engineers and
computer scientists. This means that the many building blocks in our software are
often written by different team members. Integration is the meshing of the individual
contributions into one coherent system. The use of a consistent coding style,
documentation and our software architecture reduces potential problems in this area.
To facilitate easier development and integration all team members have access to
design documents, model descriptions, algorithm descriptions, engineering
specifications and requirements, functional specifications, control flow diagrams, data
flow diagrams, source code and database files.
2.7
Integration Testing
Once the application is integrated/assembled into a complete product, there is a need
for a formal Quality Assurance testing procedure.
Before each release we undertake a formal testing procedure. Currently this testing
procedure takes about 20 man days of effort. As well as testing all aspects of the user
interface we have over 300 validation calculations.
The validation calculations are issued with each release of the software and can be
found at the following locations:
[The
[The
[The
[The
[The
folder
folder
folder
folder
folder
where
where
where
where
where
FluidFlow
FluidFlow
FluidFlow
FluidFlow
FluidFlow
is
is
is
is
is
Installed]\QA
Installed]\QA
Installed]\QA
Installed]\QA
Installed]\QA
Incompressible Flow
Compressible Flow
Non Newtonian Flow
Two Phase Flow
Scripting
Each time a user reports a bug, we add a validation example to our QA testing files so
that the likelihood of a re-occurrence is drastically reduced.
Validation examples are designed to test each calculation method used for
consistency, accuracy, repeatability. The Quality Assurance examples are also a
useful source of explaining the capabilities of the software for a new user.
2.8
Data
The calculation methods used within the application often rely on some type of
supporting data.
Typically this data may be used to describe physical properties, transport properties,
to describe pressure loss against flow relationships or to support heat transfer and
energy balance methods.
The results delivered by Piping Systems FluidFlow are dependant upon the accuracy
and relevance of input data.
Data contained in the support databases that are delivered with the application is not
all sourced, entered and validated by Flite Software NI Ltd. This is because the
databases contain data entered by our end users. In this regard we act as a clearing
house to merge data from a wide variety of users.
End users are recommended to validate all input and database data used in their
calculations.
2.9
Installation
Flite Software has made a special effort to simplify the installation process. We have
thousands of installations worldwide on a variety of operating systems.
We have code embedded in the application that checks that an installation has been
successful.
The application code is compiled into one executable file and we do not make any
changes or additions to the windows registry. For users operating in locked down
environments we supply an installation 'footprint' as an alternative.
The software has also been fully tested for use within Terminal Services, Citrix, and
Novell environments.
2.10
User Operation
All users are actively encouraged to feedback their experiences with our software.
Users can provide feedback via our website www.fluidflowinfo.com or directly via the
application.
All code within the application is routed through exception handling constructs. This
means that if the software fails in any way, it writes to a log file providing the date,
time, reason and type of each failure together with resource and status information
about the hardware where the failure occurred. This log file is called psff.elf and is
written to the same folder that holds the single application executable file psff.exe.
2.11
Maintenance
Software maintenance is the main mechanism for making improvements, corrections
and adaptations to the application.
Corrective maintenance resolves errors found during the operation of the software.
Each time a bug is reported to Flite Software NI Ltd, we verify that the bug exists and
then enter the details into our "tracking and resolution" system. We issue regular
maintenance releases.
The release numbering convention used by this product has the format [Major
Version].[Minor Version].[Build Number]. So for example if the current release is
3.11.5 the next release will be either 3.11.6 or 3.12.0. The deciding factor on the
number of the next release depends on the severity of any bugs found also on the
enhancements and improvements made.
Perfective maintenance is carried out to improve the application performance or to
add or improve other program attributes. Only enhancements or new features cause
the minor version number to change.
It is the users' responsibility to keep the software current via our website. We have a
Software Assurance Policy that enables continued access to the downloads area of our
website:
http://www.fluidflowinfo.com/Downloads/Downloads.asp
3.1
Standards Used
There are very few standards available for use when making fluid flow calculations.
Piping Systems FluidFlow makes use of the latest standards and guides where
possible.
For calculating pressure losses across control valves for liquid and gas flow the
software uses the following guide: ANSI/ISA-75,01.01-2002 - Flow Equations for
Sizing Control Valves.
For predicting all physical properties of water we use the IFC-97 formulations
10
3.2
3.3
11
3.4
12
For calculation of pressure losses across other fluid equipment items the K factor
method is used. K factors are adjusted at low Reynolds numbers as recommended by
Steffe - Non-Newtonian Flows in the Food Industry
3.5
3.6
13
Our pressure loss algorithm dynamically splits the pipe into segments based on an
incremental pressure change. The user can select from any one of 7 available models:
Whalley Criteria (uses Friedel, Chisholm or Lockhart Martinelli, selection of method
is made by FluidFlow according to the criteria of Whalley)
Drift Flux Model (2007 correlations)
Beggs and Brill (Extended Regions)
Friedel
Muller Steinhagen Heck
Chisolm Baroczy
Lockhart Martinelli
3.7
14