Integrated Product Development Using Global Workshare

Transcription

1 Integrated Product Development Using Global Workshare A White Paper Process, Power & Marine, a division of Intergraph

2

3 Table of Contents 1. Introduction Terminology Business Drivers Use Case Scenarios Design Agent Scenario Intra-Enterprise Centralized Design, Distributed Production Scenario Inter-Enterprise Distributed Design and Production Scenario Intra-Enterprise Highly Scalable Design Scenario Owner/Operator Life Cycle Asset Management Infrastructure Database Configuration Configuring Global Workshare Server Hardware Requirements Concurrent Users Project Size Estimates Access Control Data Interoperability Production Testimonials Marine Global Workshare Initial Workshare Scope Future Global Workshare Scope Lessons Learned OnShore Plant EPC Conclusion Appendix Acknowledgments References Authors biographies...18

4 1. Introduction The conditions under which modern shipyards are working today require that they become more efficient in their design and engineering activities and enhance their processes and working methods in order to reduce lead time and design cost. One way to reduce lead time in design is to subcontract all or some portion of the work to external partners at both the design and production levels. This solution affords flexibility in workforce utilization compared to the alternative of hiring more resources and it has a potential cost saving aspect. The enabler for such an environment is a design system that supports a process whereby it is possible to manage globally distributed projects from a centralized location without using excessive additional efforts in coordination and control activities. Odense Steel Shipyard (OSS) has been a founding member and integral partner with Intergraph in the development of SmartMarine 3D, which has been designed to support the vision of highly concurrent, scalable, globally distributed design as outlined in the summary above. SmartMarine 3D is architected on commercial, open, relational database technology that takes advantage of highly reliable remote data replication. This enables shipyards to support a process of working globally with design centres in distributed networks through sharing of the product model in geographically distributed sites while supporting consistent workflows through control of user permissions. The authors will present a summary of the business drivers for this requirement, an overview of the issues facing such an approach, outline the details of the implementation, highlight some production success stories and lessons learned, and summarize the advantages it has produced. Integrated Product Development Using Global Workshare Page 1

5 2. Terminology The following terminology is used in this paper: Global Workshare Configuration (GWC) refers to the concept of distributing the responsibility for some aspect of a marine project s design and/or construction across physically separate sites. Site a database server at some physical location, designated as either a host or satellite. Permission Group (PG) a mechanism to control access (i.e. the read and/or write) to objects within the database. Replication the means by which information at one site is synchronized with information at another site. Business Object (BO) refers to a software component that represents a real-world application object (e.g. a plate, a piece of equipment, a pipe, a block, an assembly, a workcenter, etc.) encapsulating the business rules, logic, and controls necessary to ensure it behaves in a consistent and predictable manner. Host Location the first site created in a GWC that controls the replication and synchronization process. Satellite Location one or more remote sites created in a GWC that contains copies of the data on the host location.. Figure 1: Marine industry global workshare Integrated Product Development Using Global Workshare Page 2

6 3. Business Drivers As noted in the terminology section and in Figure 1, Global Workshare refers to the concept of distributing the responsibility for some aspect of a ship s design and/or manufacture among physically separate sites while ensuring safe information exchange without the risk of disruptions to the day-to-day business operations. Examples of this are: delegating design responsibility for some subset of a ship s systems given to a sub-contractor by a prime contractor; responsibility for inter-discipline design tasks among design departments of an enterprise that are in different cities, states, or countries; responsibility for approving the design by a classification society; or responsibility for the manufacture of some sub-assemblies and/or blocks by outside subcontractors or by other shipyard facilities under the control of the enterprise. Not all business cases or drivers involve outside subcontractors or separated geographies. Workshare can be, and is, used to support scalability and optimization in highly concurrent design scenarios within large enterprises. Processes and procedures need to be developed and/or adapted to take into consideration such factors as permission levels that can be assigned to individual users and/or groups of users. Through use of permissions, design management can control what data can be created or changed by whom in this distributed digital domain. These types of controls are not new to shipbuilding; they exist in some form or another in every design office and shipyard in existence today. However, they are generally not formalized and structured in a manner that allows them to be exploited by today s information systems. The business innovation for the marine industry that is made possible by workshare technology is one of the most promising bright spots on the horizon. Shipbuilding and Offshore construction is cyclical, demand fluctuates, and capacity is limited. The ability to compete and survive hinges on the ability to specialize on some aspect of the overall process, whether that is producing a complete marine vessel type, or only some specific system, subsystem, or component. The ability to isolate some subset of the design data and temporarily or permanently assign responsibility for it from one group to another, while maintaining the data integrity in an integrated product model in a concurrent design environment, is revolutionary in the marine industry. 3.1 Use Case Scenarios While the business drivers outlined above may be broadly applicable across multiple industries like automotive, construction, aerospace, process, and power, it should be emphasized that advocating a one size fits all solution is not what the authors are endorsing. The marine industries have many unique characteristics associated with large, one-of-a-kind complex products that cannot be addressed with generic off-the-shelf tools. Factors such as regional vendor and supplier bases, scalability, integrated design and production processes, and management of large capital assets all combine to necessitate the need for highly specialized tools developed specifically for the industry. It is important to make the clear distinction between the need for tools tailored to and for the specific needs of an industry segment and the use of technology in the underlying architecture of the tool that applies to a broader market segment. In the case of SmartMarine 3D the tool and global workshare the technology just such an approach has been adopted. The following paragraphs detail a number of common scenarios typical of the industry and highlight characteristics and issues that present peculiar challenges to be addressed from a Global Workshare perspective. Integrated Product Development Using Global Workshare Page 3

7 3.1.1 Design Agent Scenario This scenario is characterized by a relatively low number of client users working with a high volume of evolving design models and interacting with a varied and ad hoc set of external consultants and subcontractors. The design timeframe is relatively short, ranging from several weeks to 3-4 months. The modeling activities are primarily concentrated in the design stage of the lifecycle and limited if any effort is expended in the detailing and production stages. The deliverables are primarily drawings and reports suitable for conveying design intent, concept, and estimating cost and schedule. The level of detail, need and use of standardized details and rate of change are relatively low. The amount of data reuse is extremely high, as is the need for rich catalogue content Intra-Enterprise Centralized Design, Distributed Production Scenario In this scenario, the number of design clients is very high, the volume of designs is low, and the interaction with subcontractors limited. The design timeframe is on the order of 3-6 months. The modeling activities span the design, detailing, and production stages of the product lifecycle. Deliverables are design and production drawings, reports, and Numeric Control data for plate and profile cutting, pipe bending, and robotic welding. Because this scenario is within a single enterprise, it is possible to tightly control the IT infrastructure, processes and procedures, and project execution. The projects in this scenario are typically more complex and the design level of detail, the duration of the design cycle, and the need to provide versions of the deliverables result in a high level of change that must be managed across all the design stages. The need for design standardization, automation, and rich catalogue content is high Inter-Enterprise Distributed Design and Production Scenario What makes this scenario different from Scenario above is the de-centralization of the design and production activities. In addition to the physical logistical problems this entails, controlling and managing the project is complicated by the existence of disparate IT infrastructures and processes and procedures. Access control, model synchronization, standardization, format and content of deliverables, and change management become much more important and difficult, requiring more sophisticated and specialized tools and techniques Intra-Enterprise Highly Scalable Design Scenario This is a specialized case of scenario where the focus is on optimizing and fine-tuning database configurations using workshare to balance the load between servers where the design environment is highly concurrent and interactive Owner/Operator Life Cycle Asset Management This scenario is one virtually untapped in the Marine Industry today and can be described as the onboard product model delivered to the owner operator in the form of an as-built database. The characteristics unique to this scenario are the challenges it presents to the IT infrastructure with Integrated Product Development Using Global Workshare Page 4

8 respect to database synchronization; the extended level of detail of catalogue content (vendor content, spare parts, diagnostics, technical manuals, etc.); and the duration of the operation stage of the life cycle extending over several decades for commercial vessels and approaching a halfcentury for some Naval vessels. The design level of detail and volume of change slows markedly from that during the design and production stages and is relatively low except for periods when the vessel undergoes planned, scheduled maintenance or repair, making the feasibility of live updates via satellite or periodic updates at ports of call a distinct possibility. Client access to the design stage data and catalogue, on the other hand, is extremely high and most likely needs to be supported on mobile clients. Uses of this data include training, inspection, supply, support, maintenance, and repair. Integrated Product Development Using Global Workshare Page 5

9 4. Infrastructure Database replication, while supported by functions and features in the application, is not done within SmartMarine 3D. It is a feature available from the database vendor. A full discussion on the topic is outside the scope of this paper and is left to literature in the public domain (see reference 1), however, from a high-level perspective, it involves servers playing the roles of publisher, distributor, and subscribers. The publisher is the server or database that sends its data to another server. The distributor is the server or database that manages the flow of data through the replication system, and the subscribers are the servers or databases that receive data. The role of distributor may be combined with that of the publisher on the same server. In the content of this paper, the term site is synonymous with publish and subscribe servers each of these would be a separate site that would be synchronized via replication. There are different types of replication, namely snapshot, transactional, and merge. Snapshot replication is the simplest and works by copying all replicated data from the publisher database to the subscriber s databases on a periodic basis. It is best in situations where the size of the data is not very large and the data changes infrequently. Transactional replication captures all changes and stores insert, delete, and update statements in the distributor database. These changes are then sent to the subscribers and applied in the same order as they were made. This type of replication is best for frequently changing data and large data stores. This is the model most commonly employed with SmartMarine 3D in the Marine industry. Merge replication is the most complicated and captures all incremental data changes in the source and target databases and reconciles conflicts according to rules the user configures. It is best used to support autonomous changes of data on the publisher and subscriber servers and databases. Given the global nature of today s marine user, replication and work sharing offers the potential to efficiently and effectively manage a shipbuilding or offshore project among several design teams, consultants, sub-contractors, and/or yards. The following paragraphs outline some of the necessary infrastructure for supporting global workshare. 4.1 Database Configuration From a conceptual user viewpoint, the system can be described as a single, virtual database solution. The physical implementation, however, makes use of multiple databases more or less transparent to the designer using SmartMarine 3D for the purposes of effectively and efficiently segregating the information. In order to properly setup and utilize global workshare, the database administrator must understand the databases that SmartMarine 3D uses. Figure 2 graphically depicts these databases, which are: catalogue; catalogue schema; model; site; and site schema. The Catalogue database contains reference data, which includes part dimensions and industry standards. The catalogue database is the sum total of the non-graphical information derived from the reference data (catalogue content) delivered with the software. The delivered reference data can be modified or custom reference data can be used to create a new catalogue database for a specific project. The model database contains all instances of parts in the physical representation of the model. The catalogue and model databases share the same schema. A marine design project (i.e. a ship or offshore structure) is all three databases used together: catalogue database, catalogue schema database, and model database. The site database and schema are containers for the Integrated Product Development Using Global Workshare Page 6

10 Site Schema Db Site Db Catalog Db Permissions Permissions Catalog Db Catalog & Model Schema Db Catalog & Model Schema Db Filters Filters Model Db Model Db Model Db Figure 2: Database configuration other databases. The site database stores work-breakdown and user access for the model. A site database can have multiple model and catalogue databases. Typically, there is one site database set for each customer location. The global workshare configuration (GWC) allows sharing all the data within one marine project with remote sites. Designed for companies running projects from multiple sites (EPCs or owner/operators, for example) or for multiple companies that are working on a single marine project, the global workshare functions involve a single, central database in which all the changes come together as if they were created at the same site. Pivotal in the sharing of data within a workshare environment are the geographical hubs known as locations. Two types of locations are required to share model data among multiple sites: a Host location and one or more satellite locations.the host location is a set of one or more database servers on a local area network (LAN) that contains the original set of databases associated with a site. The satellite location is a set of one or more database servers on a LAN that contains the replicated database associated with a site. The host location is created automatically and as such, the host location is the first location created. satellite locations, on the other hand, are created manually. Once they are created, locations can be associated with permission groups and models as part of the workshare replication process. In the global workshare solution, data sharing between different locations is achieved through real-time Model database replications of the entire ship at all satellite locations. The catalogue and catalogue schema databases and the site and site schema databases are maintained on the host server while satellite locations have read-only replications of these databases. For the catalogue, catalogue schema, site, and site schema, the host should control the data. The other machines are satellites of the Host. The host is a publisher of catalogue, schema, and model data to the satellites and a subscriber of model data from the satellites. The satellites are Subscribers to the host for catalogue, schema, and model data. They are publishers of model data to the host. In small and midsize configurations, the database server is usually its own distributor. However, in the case of large configurations or multiple smaller configurations, it is possible to use a dedicated distributor server. Consolidation is the process of merging back all the replicated databases on the different satellite servers to the databases on the host server so as to form a single database of each type. The resulting merged databases resemble the original databases; users can work with them as if the databases were never replicated or, at some later point in the design process, the databases can be Integrated Product Development Using Global Workshare Page 7

11 replicated again with either the same or with different satellite locations. The ability to easily grow the workshare configuration by creating additional satellite locations after the project start as demand dictates and then to just as easily shrink the configuration by consolidating databases provides the ultimate flexibility in meeting the fluctuating demands of the industry. While this setup is overhead that must be undertaken in a GWC, it is something that is typically done once at the start of the project and then run autonomously during the project execution. 4.2 Configuring Global Workshare Projects intending to use global workshare need to properly configure the hardware and software based on a number of factors, such as: The number of concurrent users per site. The number of sites. The size of the project (which translates into the size of the databases). Other software that is running on the machine. The paragraphs below provide a more detailed discussion of these factors Server Hardware Requirements At the time of writing, the following specifications are adequate for a typical database server supporting concurrent users: 4x Dual Core Processor 16 GB RAM 100 BaseT or higher network interface Digital tape or DVD backup system for server CD-ROM drive access, either locally or through a network connection For optimum performance, the server should be configured with multiple hard drives. The size of the hard drive is not as important as the speed and 15 K RPM or faster is recommended. You can add disk arrays to maximize performance and avoid I/O bottlenecks. RAID 10 is recommended for performance and redundancy. The following example shows a typical configuration for a small project using SQL Server Three disks is the recommended minimum: C: Drive Operating System and SQL Server Software D: Drive Database Files E: Drive Database Log Files A configuration for a large project using SQL Server 2005 is shown below: C: Drive (Raid 1) - 2 hard drives internal to the server for the operating system and Page File E: Drive (Raid 10) 8 SAN drives for the data file for the Model database F: Drive (RAID 10) 4 SAN drives for the Model log file G: Drive (RAID 0 or 1) 2 SAN drives for the temp database H: Drive (RAID 10) 4 SAN drives for the Catalogue, Site, Site Schema, Catalogue Schema, Report, and Report Schema data files I: Drive (RAID 1) 2 SAN drives for the Catalogue, Site, and Schema log files Integrated Product Development Using Global Workshare Page 8

12 J: Drive (RAID 1) 2 SAN drives for the Master database data K: Drive (RAID 1) 2 SAN drives for the log file Concurrent Users The size of the system depends partly on the number of concurrent users, that is, users actively working at the same time. In a GWC, it is probable that work will be done at several sites in a nonconcurrent way. In this case, there is less impact on performance. For example, if you have two sites with 60 users at each site but the users at the two sites do not work at the same time, you could consider the user load to be 60 users. In a GWC when users are working concurrently at several sites, the work done at one site will impact each site as the data is replicated to the other sites. In a hub and spoke configuration (where a single hub server is designated as the distributor and the spokes are all satellite servers), the data is first pushed to the hub and from there, pushed to the other sites effectively increasing the user load (i.e. the equivalent user load) on the servers (see Figure 3). Determination of the equivalent user load is based on the number of actual users on the server plus a factor applied to the total of concurrent users of all the other sites. For example, the equivalent user load would be less for a configuration of 6 sites with 40 users each where only 3 sites would be working concurrently say because of time-zone differences than it would be for a configuration where all 6 sites would be working concurrently. Spoke (subscriber) Spoke (subscriber) Clients Clients Hub (distributer) Spoke (subscriber) Spoke (subscriber) Figure 3: Hub and spoke GWC Project Size Estimates The model database is an important factor in determining project size, but it is not the only factor. In addition to the explicit design clients, there are remote and batch processes for such things as generation of deliverables (drawings, reports, manufacturing output, etc.), licensing, and interference detection that run as additional clients and increase the user load on the server. Characteristics for three prototypical project scenarios (small, medium, and large) are provided below: Small Project: 1 to 15 effective users on one server Integrated Product Development Using Global Workshare Page 9

13 Model database up to 8 GB Server used for model and catalogue databases and catalogue file server Separate interference checking server (or workstation) Separate batch server (or workstation) Name generator server and licensing server (or workstation) Modeling and Administrator workstations can be separate or they can use the same workstation Medium Project: 16 to 50 effective users on one server Model database 8 15 GB Databases and catalogue file server Separate interference checking (IFC) server (or workstation) Separate batch server (or workstation) Name generator server and licensing server (or workstation) Modeling and Administrator workstations can be separate or they can use the same workstation Separate distribution server for GWC Large Project: 51 to 100 effective users on one server Model database 15 GB or more Databases and catalogue file server (have a separate catalogue file server for multiple large projects or ships sharing the same catalogue) Separate interference checking (IFC) server (or workstation) Separate batch server (or workstation) Name generator server and licensing server (or workstation) Modeling workstations Administrator workstation Separate distribution server for GWC 4.3 Access Control Access control is addressed through the concept of permission groups (PG s) that play several key roles in the system. At the most basic level, they enable segregation and control of design responsibility, while at the most advanced level they enable partial backup and restore; form natural boundaries for change propagation; and are the backbone of multi-site distributed design (database replication and global work sharing). Every business object (BO) created in SmartMarine 3D belongs to one and only one PG. The system creates a default PG, however, users are free to create as many additional PG s as are necessary to control their design process. Within each SmartMarine 3D task, the user selects the PG to be used for the creation of new objects. The means are also provided to enable a user to easily modify the PG of an existing object. A PG serves as a logical grouping of BO s within the model database. Access control in SmartMarine 3D is rule-based. Access rights are defined by a list of access rules and granted to a user or a group (as defined by the operating system). The currently supported access rights are read, create, update, delete, and approve. Access control is orthogonal to data stores, that is, several data stores (catalogue and /or model databases) can support the same PG, and hence an access rule will apply to all these data stores. In general, access control is not intended to replace security. Rich clients (the client workstations on the network used by SmartMarine 3D Integrated Product Development Using Global Workshare Page 10

14 designers and engineers to model and interact with the model) have direct access to the database and security is managed by using the security features of the database vendor. When an application or a Web server hosts services, access control may be used as a security feature. PG s serve as the basic mechanism for partitioning data to support distributed design through database replication and work sharing between two or more sites. A given site has read-only access to the data of the other sites. Two sites cannot have write access at the same time to the same data. It is better when the partitioning of data does not change frequently, for example, a site is given read/write access in the morning to some data and another site is given the read/write access to the same data in the afternoon. The reason being that the partitioning of data needs to be controlled at a central location by an administrator because changing the partitioning is a heavy operation and requires that the data stores at every other site be put offline while the changes are made. As with the project setup for database servers in a GWC, setting up the proper PG s is something that is typically done once at the beginning of the project. Determining the proper PG s takes some time and thought, however, once done, it can be used as the basis for future projects where only minimal changes need to be made to address changing team players or roles. 4.4 Data Interoperability Global workshare projects based on homogenous software applications and tools can avoid having to deal with interoperability issues stemming from the need to exchange and share data. It is essential that product data can be exchanged among stakeholders in the broad process. Designers, suppliers, customers, subcontractors, class societies and others must be assured of timely access to the relevant data with full security and integrity. Sadly, despite significant investments in human and capital resources, the adoption of ISO standards for the exchange of product model data (STEP) have had a minimal impact on the ability to share data among today s shipbuilders except possibly as a kind of super-iges translator of geometry and topology. Despite the adoption of three shipbuilding-specific application protocols (AP s) over 5 years ago there are few, if any, commercial offerings of STEP translators for these AP s by software vendors in the marine industry. Whether this is because of the complexities of data to be shared, the low demand within the shipbuilding industry, or the pace of the standardization process, it remains a fact that workshare in the near-term must continue to rely on the use of similar software systems or the development of point-to-point solutions to address data sharing between systems. This absence of standards means that factors like: open architectures, the availability of floating license configurations; hardware costs; ease of use; and training requirements will be significant discriminators in technology solutions. Products like SmartMarine 3D based on commercial, relational database technology and an open architecture offer a proven path to meeting this need. Integrated Product Development Using Global Workshare Page 11

15 5. Production Testimonials Up to this point, the authors have described and discussed the technical issues underlying the adoption and use of technology to facilitate global workshare. The authors would now like to shift the focus to highlight several real-world applications of this technology in production projects. 5.1 Marine Global Workshare Odense Steel Shipyard (OSS) in Denmark started practical use of SmartMarine 3D more than four years ago, beginning on a small scale and growing at a measured pace. Today, SmartMarine 3D is the major design tool and plans are under way to phase out all legacy systems by early OSS has recently completed the design of the first in a series of a very large and advanced container ship by far the biggest ship the yard has ever built. The engineering centre in Odense did not have the capacity to design such a ship in the allotted timeframe so it was decided that subcontracted resources would be utilized. Likewise, none of these organizations had the capacity to undertake the whole design themselves and it was necessary to use a number of geographically distributed subcontractors located in Lithuania, Finland, Spain, Holland, and Germany in order to meet the schedule. Further complicating the picture, the classification society was located in the USA and the owner in Denmark. Significant key components were purchased in different countries including as far away as Japan, Korea, and China. This project became a textbook example of the need for tools and technology supporting globally distributed workshare. The following paragraphs highlight the evolution of the implementation and some of the major lessons learned during its execution, noting that this is an example of a project having the characteristics described in paragraph Initial Workshare Scope Given the situation of having a short window of opportunity for project start-up coupled with the fact that each subcontractor had resources trained and experienced with a variety of different systems and tools, it was apparent that the project would have to accommodate several different traditional, legacy CAD systems being used in parallel. While this shortened the project start-up time, eliminated the need for acquisition of new hardware and software systems, bypassed the need for training, and guaranteed a known level of productivity of the subcontractors due to familiarity with the tools, it came at the cost of rather expensive centralized, manual control and coordination efforts. In addition to being built on a commercial, relational database, SmartMarine 3D is designed with an open architecture and this enabled OSS to successfully use it as the central repository for data from all the other systems using custom XML-based import interfaces. The subcontractor models are placed directly in an SmartMarine 3D satellite database and the content of that database is replicated at the OSS site. Access, however, is controlled by the Information Technology department through permissions (See Figure 4). In this configuration, distribution of work is managed by giving the responsible site write permissions and all the other sites read permissions, thus eliminating the possibility of multiple sites modifying the same data concurrently. Release of finished work was based on or telephone communication and the same process was used for addressing and managing change. When approved, OSS generated final production information from the central database at OSS. This proved to be a practical, acceptable, and functional way of doing business. Integrated Product Development Using Global Workshare Page 12