INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT: CAD MODEL CAPTURE
description
Transcript of INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT: CAD MODEL CAPTURE
INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT:CAD MODEL CAPTURE
Ana Carolina Olivera1, Gustavo E. Vazquez1, Nélida B. Brignole1,2
1 Laboratorio de Investigación y Desarrollo en Computación Científica (LIDeCC)Departamento de Ciencias e Ingeniería de la Computación
Universidad Nacional del SurAv. Alem 1253 – 8000 - Bahía Blanca
Argentina
2 Planta Piloto de Ingeniería Química (PLAPIQUI)Universidad Nacional del Sur - CONICET
Complejo CRIBABB – Camino La Carrindanga km. 7 – CC 717 - Bahía BlancaArgentina
INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT:CAD MODEL CAPTURE
Introduction Instrumentation
Design Automatization
Decision Support System (DSS)
Software Reengineering Concept Stages
Requirement Analysis Model Capture Re-design of the DSS Conclusions
IntroductionInstrument Design
V-1
E-1
P-1
E-2
P-2
E-3
P-3
P-4
P-6P-20
I-2
I-3?
?
?
Instrumentation Design
Model Variables
UnmeasuredVariables
Measured Variables
ObservableVariables
UnobservableVariables
RedundantVariables
Non-RedundantVariables
Observability Redundancy
Decision Support System (DSS)
User Inferface
Process Engineer
Generatation Module(GM)
Generation Equation
Observability Classification
Report
Observability Module (OM)
DesiredClassification
Redundancy Analysis
Module (RM)
Redundancy Classification
Report
DesiredClassification
Final Classification
YES
NODecision Support
Tools
Decision Support Tools
NO
YES
Ponzoni I. & others et. al., 2004
Vazquez G. E & others et. al., 2001
Ferraro S. J. & others, 2002
Software Reengineering
Forward engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of the system.
Reverse engineering is the process of analyzing a subject system to: Identify the system’s components and their
interrelationships and create representations of the system in another form
or at a higher level of abstraction
Software Reengineering
Software Reengineering is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.
Forward engineering Reverse engineering
Software Reengineering
Software Reengineering - Stages
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Requirement Analysis
During its application for the analysis of industrial plants, the tool (GM) suffered several anarchical changes that mainly had to do with the addition of new items of equipment and measurements.
Those changes had been made without following a specific method and also without documenting the modifications.
The problem was partly caused by the programming language whose features made the maintenance difficult.
The upkeeping was unrelated to faults, but had mainly to do with the addition of new unforeseen functionalities.
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Requirement Analysis
The existing software was integrated to the tools for observability analysis, redundancy identification and the other modules that constituted the DSS.
Since these modules were all developed in an independent way, the interfaces did not offer the users distinctive advantages when a complex design has to be carried out.
Requirement Analysis
Their integration demanded global restructuring.
Requirement Analysis
Another important aspect is friendliness, which can be achieved by a graphical interface with facilities to visualize the flowsheet that is being created. This facility should be available at any point during the definition allowing the addition or remotion of an instrument wherever needed.
Model Capture
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Model Capture
the original design and architecture of the software was recuperated to create a representation with a higher level of abstraction.
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Model Capture
In this stage both the study of the existing documentation and the interviews with the developer of the original software are mandatory.
Firstly, all the code was scanned to find weaknesses in the implementation and in the programming language.
At this point an intensive analysis on the data structures, functionalities and software architecture is carried out to achieve the DSS original design.
The earliest implementation considered the plant topology, but it was not directly shown to the user.
Achieving the visibility of the input data was an essential goal of this reengineering.
Model Capture Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Re-design
The re-design may be carried out after having settled the requirements of the DSS and captured the original design.
Bearing in mind the advantages of the object-oriented paradigm and making use of the Unified Modelling Language (UML) (Fowler et al., 1998), this activity was successfully performance.
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Re-design
-Shape
PlantEquipment
+addProcessUnit()+deleteProcessUnit()+savePlant()
-name : String = ""-processUnits
ChemicalPlant
1
*
-listOfStream
Equipment-input : Equipment-output : Equipment
StreamComponent
-Phase
MaterialStream EnergyStream
Atributes
Operations
Class Name
Association
Generalization
Generalization
1
*
Instruments
* 1
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Re-design
-numberOfStreamHeatExchanger : Integer
HeatExchangers VesselsPumps
Vessel reactionVessel
...Column
-listOfStream
Equipment
...
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Re-design
Draw Plant1
1
«uses»
PlantInstrumentation
*
1
Plant Designer Process Engineering
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
Re-design The topology of a chemical plant must be
straightforwardly available to the engineer. Its representation is natural because it may be captured
as a directed graph. Topologically speaking, a chemical plant may be represented by a graph, its nodes being the items of equipment and its edges being the process streams.
As to the modules for observability and redundancy, they have been developed and tested carefully. Therefore, they should remain untouched. The only modification was to establish an interface and hide their implementation totally.
Source Text +Documentation
List of Requirements
Requirement AnalysisBase
Architecture
Model Capture
List of Problem
Problem Detection
Remove Problem
Problem Analysis
New Base Architecture
Change Propagation
Re-organization
Legacy
ModGen vs. DSS Prototype
ModGen DSS Prototype
DSS Prototype – NH3 Plant
DSS Prototype
DSS Prototype
Conclusions
In this work we only discussed the first two stages in the re-engineering procedure.
In this paper reverse engineering has been addressed since we have explained how to deal with complex software resulting from a chaotic generation by the constant incorporation of new tools.
It was discussed how to re-adapt it by means of the software reengineering approach, so that it fulfils a standard programming and becomes transparent and reusable.