Corrientes Piso 3 - Of C1042AAA Buenos Aires - ARGENTINA - Telefax (5411)

Transcription

1 RELSOFT S.A. ENGINEERING SOFTWARE Corrientes Piso 3 - Of C1042AAA Buenos Aires - ARGENTINA - Telefax (5411) Internal Doc. Buenos Aires June, RS17101 Ref: Comparison between (REBIS) and (RELSOFT) 1. SCOPE In this document the main characteristics of two AutoCAD based Plant Design systems are analyzed and compared. It is not a complete analysis of all their features, only those meaningful from the point of view of their use and on behalf of the comparison are taken into account. is a development of REBIS, an USA company. The first version goes back to the late 80'. It is the result of developments of two companies that merged about five years ago. The information presented here was gathered from public sources and from interviews with users. is a development of our own RELSOFT SA company, based in Argentina. The first version was on It was developed as a 3D Piping and Equipments modeler and Plans and Isometric generator, along with an integrated Material Management system. As regard to its performance, directly competes with PDS system (Intergraph) and PDMS (CadCentre), both recognized as market leaders. With respect to, we tried to obtain the best possible information, but we have not the same amount of data available as for EPLANT. Nevertheless we feel confident that the main features are fairly accounted for. 2. COMPARISON For presentation clarity, both systems are analyzed grouping together the most important aspects and basic functions. In each group, the upper part of the table contains the analysis information, while the bottom part includes comparison references. 1 / 12

2 Compararison between and - RS SYSTEM ARCHITECTURE Almost all Rebis applications work with a similar architecture: an application program running in an AutoCAD session with data generated in an AutoCAD (DWG) drawing file and a Microsoft ACCESS (MDB) external data base. Synchronism between both types of files is maintained from the application. The Plant Design module uses the Data Base Module to access piping specifications and the Part Catalog, which is stored in ACCESS format. Each application is made by different modules, without a clear developing trend. Was there any need to develop a 2D module, as the one recently developed, or to have an isometric drawing module, when the real advantage is working with 3D models? is build around a graphic application running on AutoCAD, interacting with DWG and DBF files, and a Data Base module in Microsoft FoxPro to manage Specifications, Dimensional Standards, Material Codes and to automatically generate Material Requisitions. The graphic module stores information in AutoCAD drawing files only. The data base module manages all information not graphic-specific. The initial schema using 3D models, Plan and Isometric extractions and Material Requisition generation has been maintained and improved and shares this trend with the best plant design software. It relies on third parties using old technology (Isogen) for basic features. 2 / 12

3 Compararison between and - RS FILE SIZE Piping models: - graphic (DWG) = 150 kb / line - data base (MDB) = 200 kb / line With those values a project has the following size: 100 lines = 15 Mb (reasonable limit for one model) 1000 lines = separated files for a total of 150 Mb Equipment models: not enough data to elaborate a statistic. Structure models: the same as equipments. Piping models: - graphic (DWG) = 13 kb / line - data base (MDB) = internal to the DWG With those values a project has the following size: 400 lines = 5.2 Mb (practical limit for one model) 1000 lines = separated files for a total of 13 Mb 5000 lines = separated files for a total of 65 Mb Equipments models: kb / equipment 100 equipments = 2 Mb Structure models: 700 bytes / object 1000 components = 0.7 Mb Uses graphic elements generated by the application that occupy a lot of space in the DWG file. Privileges graphic representation versus file size. Drawing file structure was specifically designed to take advantage of compression features of the AutoCAD format. Moreover, all non graphic information is stored in the DWG file in a compressed format; no information is stored in external data bases. 3 / 12

4 Compararison between and - RS AUTOCAD COMPATIBILITY Very limited: without Autoplant, 3D models are visible only installing a special Viewer supplied by Rebis. There is no warranty that Rebis objects would be compatibles with future AutoCAD versions. Now they are incompatible. Storing associated characteristics in an external data base, forces the application to maintain data synchronized in different files. For this reason, it is not compatible with AutoCAD native edit commands and cannot fully support the Undo. It is weak with respect to drawing file modifications using AutoCAD alone. It is fragile with respect storing plant important information for large periods of time: future AutoCAD versions could not even have a way to visualize that information. Complete: all graphic elements are AutoCAD native graphic primitives. All AutoCAD edit command like copy and delete can be used. Absolute guarantee to be able to access to models using AutoCAD alone, for future version also. It was specially designed to guarantee a seamless integration with an AutoCAD session: all the information is stored in the DWG using a compress format, native AutoCAD command copy and duplicate the associated information also, although they do not interpret it. It is strong with respect to drawing file modifications using AutoCAD alone. It is AutoCAD compatible for any future use of the graphic information. 4 / 12

5 Compararison between and - RS INFORMATION DISTRIBUTION Difficult: without Autoplant, 3D models are visible only installing a special Viewer supplied by Rebis. To query model component properties, an Autoplant license must be installed. Easy: all graphic elements are AutoCAD native graphic primitives, without exceptions. The intelligence associated to models can be queried using the evaluation version, distributed without charge and very easy to install. It allows to distribute the graphic information without requiring any EPLANT license. 5 / 12

6 Compararison between and - RS PIPING COMPONENTS PARAMETRIC DEFINITION No information was found at this respect, but it looks like that the user cannot modify existing components nor define new shapes. Interviewed users admit that they routinely use dumb AutoCAD blocks in these cases, adding them to 3D models, plans, isometrics and MTO. Closed to new shapes. All piping components are parametrically defined using sentences in a specialized language, loaded in text files. Users can modify any existing shapes and define new ones. Open to modify and create new shapes. 2.6 PIPING COMPONENT DIMENSIONAL TABLES They are copied in the piping specifications, respecting the original system architecture. Each component dimension is stored in DBF files, placed in the corresponding dimensional standard directory. New standards can easily be incorporated defining a new directory. Dimensions can be manually loaded also during component placement. Mixes and duplicates data that is generally stable (Dimensional Standards) with specifications that are project dependable. Informations that have different modification scope are kept in separated places. Stable reference information is not duplicated: any change is automatically propagated to all projects. 6 / 12

7 Compararison between and - RS PIPING SPECIFICATIONS Uses a table to load parameters and descriptions, which must be repeated in every different instance. Properties must be assigned to each diameter individually, because each entry defines dimensions also. It allows to update 3D models against specification changes, but limited to description changes. Uses a table where parameter values (rating, schedule, etc.) are directly loaded along with three codes that associated generic and detailed descriptions (the later used in Material Requisitions) and material identification. Properties are assigned by diameter ranges. It allows to update 3D models against any kind of piping specification modification. Using descriptions instead of codes, implicitly allows to associate different descriptions to the same component. This along with the impossibility to use diameter ranges, increases the work of specification definition and material errors. Lacking codes induces to use the long description field to load the whole component description, dangerously doubling information that is already specified in the class in the form of values associated to parameters. Respecification is limited to description changes only. Changes in fundamental class parameters (rating for example) must be done manually, with chances of making material errors. The generalized used of codes assures description consistency in an easy way: each descriptive text is defined in only one place and each instance references it using the corresponding code. This relational schema allows also to associate to the same project descriptions in different languages, simply modifying the project language. Respecification includes any specification parameter change: models can be modified to exactly match piping classes, no matter how many changes are made. The consequence is a better engineering standard. 7 / 12

8 Compararison between and - RS MATERIAL CODES An arbitrary alphanumeric code can be loaded in a field of the piping specifications. Allows to work with three different material codes at a time: Internal: is generated using an algorithm to concatenate EPLANT internal codes and parameter values. External: uses a translation table between EPLANT internal codes and an arbitrary code. The association rule can be any, contain the diameter or not. It allows to adapt to any codification schema. Alternated: uses the same mechanism as the External code, but with a different table. Each one of these codes can be referenced in any report. The code is not uniquely related to the material: the same material may be assigned to different codes because the association must be done in each instance in the specification, for each diameter and for each class. This schema increases the chance of making material errors during specification generation or modifications, loading the same information in different places. The Internal code is generated by an automatic process: each material always receives a unique code without requiring any additional task. The External and Alternate code allows to define a code without any dependence from specifications: the same material with the same description will use the same code anywhere in the project. It is a very useful option to handle customer internal codes. In both cases it assures in an easy way the MTO consistency, using the same code to the same material. 8 / 12

9 Compararison between and - RS MATERIAL REQUISITIONS The model report is the only available material take off, using the same field defined in specifications. The user must check the synchronism between the data base model and the graphic models. Allows to easy verify the report status of each 3D model. Automatically integrates the material of all project models and allows also to manually load material with the same format and using the same specifications (to be able to do early purchase orders based on estimated quantities). Automatically Generates Material Requisitions, grouping materials with definable criteria. Allows to generate different revision at different project stages, allowing an automatic tracking of previous quantities. Material Requisitions must be manually generated or by using an external program. Material Requisitions can be directly used for bidding and purchase orders. EPLANT is the only Plant Design system with automatic Material Requisition generation capabilities. 9 / 12

10 Compararison between and - RS PLAN EXTRACTION Plans are obtained as 3D model views. Annotations are manually placed. The huge size of 3D models, also for small plants, makes plan files very heavy to work with. The intrinsic viewing incompatibility with AutoCAD makes difficult the plan distribution among different contractors not having Autoplant licenses. Intelligent projection views are generated by a suitable command. These views can be dimensioned and annotated in a way similar to Autoplant. Views can be left in 3D models or moved outside to external files. Views are made of AutoCAD native elements only, which can be edited with standard AutoCAD commands. Allows to distribute plans to contractors that only have AutoCAD. The plan intelligence can be queried with the Evaluation Version also, free of charge. 10 / 12

11 Compararison between and - RS ISOMETRIC EXTRACTION Although Autoplant has an internal isometric extractor (but all reference must be manually added) the minimum alternative seems to be using AutoIsogen Plus, which generates the isometric drawing completed with format, MTO, dimensions and notes in a 2D file without intelligence. Isogen uses old technology, with limited and difficult configuration options. Autoplant has also a module to directly draw isometrics. The isometric is generated in a fixed view and without any intelligence. Being 2D, in the cases in which the information is not clear, users generally opt to modify it manually (the North change is apparently not very easy). Being without intelligence, any additional note or dimension must be manually added. The isometric module seems the remnant from a loose development history. EPLANT uses an internal isometric extractor, which generates an intelligent 3D drawing file for each extracted line. The isometric is generated completed with format, MTO, dimensions and notes. Automatically supports connectivity with attached xref drawing files. Uses the latest technology for data extraction: few seconds to extract each line. Setup is very easy. The isometric is intelligent and 3D. Being intelligent, any extra needed note or dimension can be automatically added. Being 3D it can be reoriented and stretched any time to better suite graphic readability. Automatic xref connectivity support allows to work in projects separated into many different models with absolute reference consistency. 11 / 12

12 Compararison between and - RS SUMMARY Although this study is not exhaustive, allows to reach the following general conclusions: - Drawing graphic files. drawing file size is almost 15 times less compared with the same Autoplant files. This allows to use EPLANT also for big projects (for instance 5000 piping lines or more) and excludes Autoplant for the same reason, because AutoCAD practical limits with big files. - Materials. Autoplant material management is weak due to poor architecture, requires additional processing to generate Material Requirements. EPLANT has a more solid architecture using codes with a relational data structure and has been designed as a Material Management system to deliver up to Purchase / Bidding Material Requisitions. - Isometrics. The isometric extractor is fully integrated in the application and generates 3D intelligent drawing files. Autoplant uses the Isogen old technology, generating 2D dumb files and it is difficult to configure. - AutoCAD. is 100% AutoCAD compatible and 3D model intelligence can also be queried with the free Evaluation Version. Autoplant requires a special Viewer even to visualize models. - Component Catalog. Open to the user to define new shapes and dimensions in EPLANT. Closed to new shapes and open to new dimensions only in Autoplant. 12 / 12