INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT: CAD MODEL CAPTURE

1. 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 Sur Av. 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 Blanca Argentina

2. Introduction Instrumentation Design Automatization Decision Support System (DSS) Software Reengineering Concept Stages Requirement Analysis Model Capture Re-design of the DSS Conclusions INSTRUMENTATION DESIGN FOR AN AMMONIA PLANT:CAD MODEL CAPTURE

3. IntroductionInstrument Design ? ? ?

4. Instrumentation Design Observability Redundancy

5. Decision Support System (DSS) Ponzoni I. & others et. al., 2004 Ferraro S. J. & others, 2002 Vazquez G. E & others et. al., 2001

6. 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

7. Software Reengineering Forward engineering Reverse engineering • 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. Software Reengineering

8. Software Reengineering - Stages

9. 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.

10. 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.

11. Requirement Analysis • Their integration demanded global restructuring.

12. 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.

13. Model Capture

14. Model Capture • the original design and architecture of the software was recuperated to create a representation with a higher level of abstraction.

15. Model Capture • In this stage both the study of the existing documentation and the interviews with the developer of the original software are mandatory.

16. Model Capture • 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.

17. 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.

18. Re-design

19. Re-design

20. Re-design

21. 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.

22. ModGen vs. DSS Prototype ModGen DSS Prototype

23. DSS Prototype – NH3 Plant

24. DSS Prototype

25. DSS Prototype

26. 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.