IMGS White Paper Template - Process, Power and Marine · So, what is cPLM, and how is it different...

1. Foreword

Designing, fabricating, and deploying a ship or offshore structure is a capitally intensive and

time-critical exercise. Top design, engineering, construction, and operating companies are now

looking to new and innovative capital project life cycle management (cPLM) technologies and

methodologies to deliver competitive advantage where “time to market,” “time in market,” and

“optimized operations” are key performance metrics.

However, cPLM should not be confused with traditional product life cycle management (PLM),

which has been used to great benefit in the discrete (aerospace, automotive, electronics, and

consumer goods) manufacturing industries for many years. cPLM is more expansive than PLM

for “engineer to order” manufacturing strategies.

So, what is cPLM, and how is it different from PLM? This white paper – written and prepared by

Intergraph– will explore the technical and business differentiators between cPLM and PLM. The

inherent differences between the two technologies as they apply to the shipbuilding, marine, and

offshore development industries will be explored.

Professor Jang-Hyun LEE, Ph.D.

INHA University, Department of Naval Architecture and Ocean Engineering

Metropolitan INCHEON, South Korea

Professor Jang-Hyun LEE received his Ph.D. from Seoul National University in 1999. He then

joined the Research Institute of Marine Science Engineering at Seoul National University.

Beginning in 2001, he directed the Digital Manufacturing System Projects at Samsung Heavy

Industries.

In 2004, he served as a PLM consultant and developed a PLM-implementation plan for STX

Shipbuilding. In addition, he led the ship design system and PLM system project for the Korean navy.

Today, Jang-Hyun LEE is an assistant professor of naval architecture and ocean engineering

at the INHA University in INCHEON, Korea, where he organized the e-Manufacturing & PLM

Laboratory and has conducted research and taught. Since joining INHA University in 2005, he

has directed PLM projects granted by Daewoo Shipbuilding and Marine Engineering (DSME).

He has published several papers on PLM, and is now researching how cPLM and data-centric

design can further benefit the marine industry.

cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries Page i

Table of Contents 1. Foreword .................................................................................................................................. ii

2. cPLM vs. PLM (Capital Project vs. Product) ....................................................................... 1

3. Capital Project and Product Manufacturing Differences.................................................... 2

3.1 Few Products .................................................................................................................................. 3

3.2 Finite Production Capacity............................................................................................................. 3

3.3 Few Configurations ........................................................................................................................ 3

3.4 High Cost, Capital Intensive (Product and Manufacturing) ........................................................... 3

3.5 Millions of Objects and Relationships ........................................................................................... 4

3.6 Specify and Order Before Design Completion .............................................................................. 4

3.7 Build as the Product is Designed ................................................................................................... 4

3.8 Evolutional, Dynamic, and Variable BOMs .................................................................................. 4

3.9 Heavy Regulation, Safety, and Hazardous Materials ..................................................................... 5

4. Technology Differentiation ..................................................................................................... 6

4.1 Data-centric vs. File/Part-centric ................................................................................................... 6

4.2 Data Sharing vs. Data Exchange .................................................................................................... 8

4.3 Managed Inconsistency vs. Enforced Consistency ...................................................................... 11

4.4 Topological Networks vs. Hierarchical Assemblies .................................................................... 15

4.4.1 Find What You Need by What You Know ................................................................. 16

4.4.2 Evolving BOM ........................................................................................................... 16

4.4.3 Change, Impact, Analysis, and Management .............................................................. 17

4.5 Integrated Disciplines vs. Digital Mock-up ................................................................................. 17

4.6 Configuration Management for Derivatives vs. Variants ................................................................... 18

5. Conclusion .............................................................................................................................. 19

cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries Page 1

2. cPLM vs. PLM (Capital Project vs. Product)

There are two fundamental components of a cPLM or PLM strategy nicely summarized by Michael

Grieves, author of Product Lifecycle Management: Driving the Next Generation of Lean Thinking

(McGraw-Hill, 2006). He writes:

“Product Lifecycle Management (PLM) is an integrated, information-driven approach

comprised of people, processes/practices, and technology, to all aspects of a product's life,

from its design through manufacture, deployment and maintenance – culminating in the

product's removal from service and final disposal. By trading product information for wasted

time, energy, and material across the entire organization and into the supply chain, PLM drives

the next generation of lean thinking.”

If we quickly differentiate between these two approaches, it would be the following:

PLM – The design process executes and derives every bill of materials (BOM) for the

product BEFORE any production and procurement begins. The design BOM is divided

into manufacturing BOM groups for production plan. Production commences on many

identical products or pre-determined variations of the BOM.

cPLM – Design and procurement begin at the same time. The manufacturing BOM

evolves from initial BOM. Procurement BOM changes DURING design evolution.

As such, it is clear the processes, practices, and technology for these two approaches are

fundamentally different.


3. Capital Project and Product Manufacturing Differences

The key difference between companies operating in either of these spaces can be summarized

between these phrases – “engineer to order” and “engineer to stock.” Engineer-to-order companies

are typically project-driven, whereas engineer-to-stock companies typically produce product

without a specific customer in mind. The table below highlights these differences:

Engineer-To-Order (ETO)

Capital Projects

Engineer-To-Stock (ETS)

Discrete Manufacturing

Few products Thousands of products

Few customers Many customers

Finite production capacity Variable production capacity

Few configurations Thousands of configurations

High cost/capital intensive (product & mfg) Global variance (design/build anywhere)

Millions of objects and relationships Thousands of objects and relationships

Specify and order before design completion Optimize sales and supply chain post design

Build as the product is designed Preparation for mass manufacture of the product

Evolutional, dynamic, and variable BOMs Manufacture against finalized BOMs

Heavy regulation, safety, hazardous materials Automation of production line

Product in service life >20 years Product in service life <10 years

Clearly, the processes/practices on either side of this “product-definition” spectrum will

be different:

On the left-hand side – the capital project – the product is typically the plant, ship, or

facility delivering the product

On the right-hand side – discrete manufacturing – the product is the product or service

ultimately delivered to the end-user by the former


3.1 Few Products

A shipyard essentially sells its production expertise for delivering to the customer a marine

structure on time, on budget, and within its operational parameters. A yard may even specialize

in one form of product, such as ships of the same size, range, or type (European yards specializing

in cruise ships; Japanese yards in bulk carriers; Korean yards in LNG/FPSO/containers, etc.). In

other words, a shipbuilding company doesn’t speculatively “build to stock” products it might sell

on the open market; rather, each order is a project, a capital project.

In contrast, a car manufacturer designs, assembles, and sells many different products – a range

of cars with multiple options and variations “engineered and built to stock” for the open market.

Therefore, cPLM is focused on project execution – meeting the delivery deadline – as opposed to

PLM, which is focused at meeting a market window of opportunity.

3.2 Finite Production Capacity

Throughput of the shipyard – the ability to fabricate, commission, and float out the product –

is critical to commercial success. Consequently, shipbuilding is a concurrent engineering and

manufacturing task. Just-in-time design, just-in-time fabrication, having materials and resources

on hand for both, and optimizing the production of the laydown yards and dry docks all mean

that cPLM is for concurrent and multiple project execution against a finite capacity plan.

This is in contrast to a discrete manufacturer who, based on market demands, could build a

production facility at another location, or reduce the assembly workstation to bolster lead time.

3.3 Few Configurations

“Experienced design” in shipbuilding is a process of deriving a new ship from previously existing

executed projects. Essentially, it is the process of harvesting and harnessing the knowledge from

previously successful projects to rapidly respond and deliver to the customer. These derived

configurations are more concerned with reuse and re-purposing than they are about managing

multiple variants, options, and alternatives.

cPLM is focused on derivative management. PLM, however, focuses on variants, options, and

alternatives for different markets and customers.

3.4 High Cost, Capital Intensive (Product and Manufacturing)

As indicated in Section 3.2 Finite Production Capacity, new production facilities are not a viable

option. It is critical to optimize and streamline the available resources, production schedule, and

material availability. Any days shaved off production not only yield extra capacity availability for

the shipyard, but also extra production capacity for the customer (and reduce interest payments on

the capital invested).

Therefore, cPLM’s focus is on cost management and progress against schedule rather than sheer

production capacity and volume delivery, which is the focus of PLM.


3.5 Millions of Objects and Relationships

Data volumes in shipbuilding are huge. An FPSO, for example, may run into millions of objects

and relationships which have numerous iterations. Sharing the correct information between

multiple disciplines in a concurrent engineering environment is vital.

As a result, cPLM views accuracy, validity, integrity, quality, timeliness, change impact, and

change management as critical success factors.

3.6 Specify and Order Before Design Completion

Many items on a ship or marine structure are not available “off-the-shelf” and need to be ordered

as early as possible before the design is complete to ensure their availability as required during

fabrication. For that reason, the BOM not only needs to distinguish between what is and isn’t

ordered, but also needs to synchronize the delivery to the yard as required. Of course, once ordered,

the change management capabilities of the cPLM need to prevent or escalate changes that would

affect these ordered items.

The cPLM focus is on just-in-time fabrication versus planned, just-in-time manufacturing for PLM.

3.7 Build as the Product is Designed

The limiting factor of the ability to deliver more ships is the finite production capacity of the yard.

Therefore, design and fabrication must execute simultaneously. The yard cannot wait for the design

to be complete, nor can it wait for materials and package units to all be available when fabrication

commences.

The cPLM needs to facilitate inter-discipline communication and collaboration and be proactive

with change impacts to and from design, procurement, and fabrication. Its focus is on agility, not

planned predictability.

3.8 Evolutional, Dynamic, and Variable BOMs

As the design is progressing and changing, so, too, will the BOM. It will be evolutional, dynamic,

and variable. Material rollups and shipping reports stores/warehouse usage will be different day by

day. This is completely opposite from discrete manufacturing where the BOM must be known and

finalized prior to manufacture. Additionally, tracking which material has been consumed on which

vessel in fabrication for cost management reporting ensures schedule and cost management.

The cPLM focus is on evolutional, dynamic, and variable BOMs, not fixed and final BOMs.


3.9 Heavy Regulation, Safety, and Hazardous Materials

Ships and marine structures must operate within a strict regulatory framework, as well as in a

safe manner, often while transporting hazardous materials. Having this safety structure integrated

during intelligent design is an obvious advantage. cPLM must support experienced design, as

indicated earlier, and also collaborate with regulatory and classification societies. The automation

and established rules need to guide and monitor the design and fabrication process.

In cPLM, rules and automation are imperative, rather than unconstrained innovation as found

in PLM.


4. Technology Differentiation

If the processes to develop the “product” on both sides of this design and manufacturing spectrum

are different, the cPLM and PLM technologies are different as well. However, what is often

confusing is that the terminology looks identical at a high level. For instance, any PLM software

vendor or document on the subject will refer to the following requirements for a PLM system:

Product data management

Document management

Configuration management

Engineering change management

Product and process definition

Collaboration applications

Visualization/viewing/reviewing

Data exchange and data integration

Program management

Interfaces for heterogeneous CAD

Others – regulatory compliance, warranty/service, spares/consumables/replacements,

catalog management, requirements management/tracking, MRO

What is not immediately obvious with the above list is the technology required to deliver these

functions. It differs for cPLM and PLM. This is as much because of the heritage of the software

vendors as it is about the functional requirements.

cPLM (Capital Project) PLM (Discrete Manufacturing)

Data-centric File/part-centric

Data sharing Data exchange

Managed inconsistency Enforced consistency

Topological networks Hierarchical assemblies

Integrated disciplines Digital mock-up

Configuration management for derivatives Configuration management for variants

4.1 Data-centric vs. File/Part-centric

Traditional CAD/CAM systems evolved from a paradigm in which the software application would

read/write to a file. In mechanical CAD systems, this invariably meant a file represented a part, and

visualization or digital mock-up software manipulated how the parts were assembled together. This

methodology is still appropriate in discrete manufacturing companies where the parts can be isolated,

and various tools – such as CADD, FEM/FEA, and CNC – can all work on the same file format.


CAD for the process, power, and marine industries originated from the same roots, but exposed

some fundamental limitations of the approach. A single file could not support the size of a whole

ship, nor could it accept writes from multiple users. Consequently, the ship would be divided into

many files, where each file may represent a ship’s block, as illustrated below. However, systems

such as a piping, instrumentation, electrical, etc. would need to span across these files.

The simplest solution for most software vendors was to leave the CAD engine largely intact,

but develop software (PDM) for their tools to communicate between the files via a database

application. This software would manage the interfaces, whether they be logical (e.g., from/to)

or physical (e.g., coordinates) connections between the files. This approach applies equally to

schematic (for example, to accommodate “off-page connectors”) and 3D software applications,

and works fine up to a point.

However, as shipbuilders started to optimize their vessel designs into configurable blocks

to support modularity and experienced design, the integrity of the network systems (piping,

electrical, instrumentation) was put at risk as each discipline modified their data within each file.

The development of digital mock-up (DMU) software partially addressed this problem, essentially

putting the whole model back together again to ensure the connectivity/integrity of the interfaces

between each file. But the software would also need to interrogate and extract specific data from

each file to establish “line list,” “bill of quantity,” “center of gravity,” etc. So the question now is,

“Is the source of the truth now in the files or in the database?”


Different CAD software with distinctive file formats would exacerbate this assembly,

interoperability and data access problem. This, in turn, leads to initiatives to standardize

the file formats (e.g., JTOpen or STeP [ISO10303]) for this data exchange to occur.

Obviously, there is a case to be made that much of the value in the engineering process was

in the data, not the file. The solution was the design engineering tools should interact with a

database, not a series of files that exacerbated the exchange problem.

Intergraph’s SmartMarine® Enterprise suite of tools is data-centric. It is a rule-driven solution

for streamlining design processes while preserving existing data and making it more usable and

reusable. A user interacts with the application that reads/writes to a multi-user, multi-discipline

database, not with a CAD system that reads/writes to files on the file system. Drawings and

document deliverables are reports derived from the database.

4.2 Data Sharing vs. Data Exchange

One of the inherent benefits of a database approach versus a file-based approach is the apparent

immediacy of data being available to all applications and users almost instantaneously. We can

think of it as this simple analogy:

In a database, data is free-flowing and available

to multiple sources. Everyone in the database is

surrounded by and soaked with data. It is free-flowing

and constantly changing.

In a file-based system, data is locked inside, much

like a castle. Access to the data requires a key to the

fortress. What goes on inside the fortress is invisible

to those outside.

What is the fundamental difference between the terms “sharing” and “exchange” in the context of

the above and the engineering process? The following simple example helps illustrate this concept.

Imagine there are two different disciplines (process engineering and mechanical engineering) using

two different applications as part of the design process – a 2D schematic P&ID application and a

3D physical modeling application. At the start of the project, the process engineer places a pump

symbol in a P&ID system and names it P-101. While the 2D schematic is being refined, the 3D

designer needs to start work and requires preliminary design information from the process


engineer, and so places P-101 in the 3D model. Later on in the project, the process engineer

determines that the pump P-101 needs a hot-standby pump and renames P-101 to P-101A and

adds P-101B.

This may be a simple change. But what could this look like with respect to systems sharing versus

exchanging data?

A methodology setup for exchange would take a scope of data from the primary application

(P&ID) and extract it into an exchange file of some predetermined format (potentially with data

mapping and transformation). It may be stored somewhere – perhaps on the file system or a

PDM/PLM system. Subsequently, a user would load the data into the second application (3D).

But what would be loaded?

In the first exchange, the “exchange file” would incorporate the details of pump P-101. In

the second exchange, pump P-101A and P-101B would be included. How would the second

application determine there were not now three pumps – P-101, P-101A, and P-101B –

but instead, P-101 had not been deleted, but had simply been renamed to P-101A? See the

following illustration.


Sharing, therefore, requires that a deeper level of information is made available on both sides of the

application divide. This information needs to encompass changes, renames, updates, and deletes,

otherwise known as CRUD. Additionally, both applications need to act on them accordingly. See

the following illustration.

SmartMarine Enterprise employs a system of data sharing through a common, application-

neutral data warehouse. This methodology supports the sharing of data from any third-party

application using standardized interfaces, which dramatically reduces the need for fragile

point-to-point interfaces. Each application provides a common interface to share and accept

data through a negotiated transaction. This is presented as a “to-do list” in which the user may

choose to accept or reject the information arriving from other applications. It ensures the engineer

is in control of his or her own data at all times.


4.3 Managed Inconsistency vs. Enforced Consistency

Engineering is not a volatile, real-time process. Nor is it one in which consistency across different

disciplines can be rigidly enforced.

If the facts were changing in real time, no decisions could ever be made or relied upon. Consider

this example:

A piping engineer has to place a hanger for a pipe system onto some supporting steelwork. If the

structural engineer were changing/moving the structural member at the same time and the piping

engineer were seeing this, he or she would never be able to complete his or her work. As a result,

the piping engineer needs to work with the latest released data, while the structural engineer moves

on with his or her design, but both need to be notified as appropriate when the object of interest is

in the process of being changed.

If data consistency between disciplines were rigidly enforced, it would be like making decisions

on shifting sand. Consider another example:

Referring back to the “pump P-101” example mentioned earlier, we’ll return to the scenario

halfway through where the process engineer had created P-101A and P-101B in the P&ID that was

made available to all other applications in “real time.” The 3D designer subsequently decided to

delete P-101B from their model and make P-101A a different capacity. What would happen to the

process engineer’s data in the P&ID? Would it simply be removed or changed? Imagine coming to

work one morning to find all the information you had created the previous day had been changed.

Trust in the information would soon be lost. Imagine how such a system would quickly fall into

disuse.

Engineering is an iterative, negotiated process where decisions are made at certain points in time

against best available and qualified facts. Those facts will change throughout the life cycle. Change

is inevitable and the substance of an evolving design. Changes will not all happen in harmony at

the same (real) time.

At any point in time, the data across the enterprise between disciplines will actually be inconsistent.

This is not inherently a bad thing. It is the normal state of an engineering project. Engineers from

different disciplines iteratively work on their own data, share data with others, and drive out the

inconsistencies through a process of sharing transactions. It does mean, however, that these

inconsistencies will need to be managed to avoid costly errors.

This milestone management is the traditional version/revision/issue/release process that

engineering disciplines working in a concurrent engineering environment accept as best

practice. In other words, the data for each discipline requires segregating until it is released

or made available to another discipline.

The process by which data is made available may vary from system to system. In a traditional

PLM (file-based) system, this release process usually involves either changing access permissions

on the file to allow other disciplines to check-in/out the file, or providing digital mock-up (DMU)

software to create an aggregate view of the different discipline files. Nonetheless, as discussed

previously, this file-based approach does not lend itself to real “sharing” and reuse of the data.


For a data-centric cPLM, an alternate methodology to check-in/out and DMU is required. Some

have argued for a unified “mother-of-all-databases” (MOAD) where data is concurrently shared

between multiple disciplines to enforce consistency. But this approach fails for the segregation

reasons indicated above.

Class-leading cPLM systems, such as SmartMarine Enterprise, utilize a paradigm of publish/

retrieve between segregated data domains to achieve data sharing between disciplines.

This practice of “publish/retrieve” is a fundamental component of a cPLM system. One discipline

publishes its data when it reaches a certain stage (when ready to share it with other disciplines) and

notifies interested parties in other disciplines that new information is now available for them. When

those disciplines are ready – either before or after their own publish milestone – they may choose

to retrieve that data into their application.


Therefore, each discipline’s published data is kept application/discipline-specific. There will be

no possibility for engineers to overwrite data that does not belong to their application or discipline.

Naturally, there will be the possibility for common data to be inconsistent between applications.

Intergraph’s SmartMarine Enterprise manages this capability by publishing/retrieving between the

tools via SmartPlant® Foundation (SPF) and its multiple data domain design.


The cPLM system must, therefore, monitor, report on, and allow this data to be made consistent

during the life of the project. The following screenshot illustrates inconsistent data regarding a

single instrument published by a number of applications residing in SmartPlant Foundation. The

first column shows the data last published. The other columns represent the same data as published

by other applications. Where the data is inconsistent between published domains, it is highlighted

for the relevant discipline to correct – it is the equivalent of the traditional engineers’ “yellow-

lining” squad check.


4.4 Topological Networks vs. Hierarchical Assemblies

PLM in discrete manufacturing evolved from PDM technologies. These systems, as indicated

previously, were designed to manage the various files created by CAD/CAM/FEA tools. Not only

did they manage the metadata (e.g., title, author, revision, etc.) of the file, but they also managed

the relationships between these files to represent various hierarchies – such as assembly, bill-of-

quantity, as-designed, as-manufactured, etc. Manipulation of the views, such as filtering out

relationships of a specific name, allowed users to manipulate the various structures. By extracting

the properties from the file (as indicated earlier), the user could develop a view specific to a

business purpose (e.g., BOM).


However, the accuracy of this BOM is limited due to a number of factors, including, but not

limited to, the frequency of exchange/extraction of the data from the source files and the frequently

changing lengths of the network segments (see Section 4.1 Data-centric vs. File/Part-centric).

Piping, instrumentation, electrical, and HVAC are not easily managed in such flat, hierarchical

views since they are networks. They are topological, often with multiple start and end points.

Conceptually, they are more like a molecular matrix than a flat hierarchy.

This image is of a molecular matrix representing a topological

system, where the spheres represent nodes or objects.

This image shows a flat hierarchy representing an assembly where

the spheres represent nodes or objects.

Why is managing such a topological network in a data-centric environment important?

4.4.1 Find What You Need by What You Know

In a hierarchical system, the structure and its nomenclature are defined in such a way that everyone

who knows it can find what they need. But it means that navigation is not always intuitive, and it is

impossible for casual users who do not understand the structure. In a molecular network, the nodes

and objects represent things of interest to multiple disciplines during the project life cycle (e.g.,

blocks, systems, areas, equipment, documents, drawings, suppliers, purchase requisitions, process

plans, etc.). Users can start at any point on the network about something they do know and navigate

to where they need to be. By integrating this “query by relationship” with more traditional “query

by example” (metadata search) and “query by content” (full text-retrieval search), a cPLM system

accommodates all classes of user – from the “information professional” to the “casual user.”

4.4.2 Evolving BOM

One thing is certain about a marine or offshore structure. Until it is finally complete and deployed,

its BOM will constantly evolve as design and fabrication occur simultaneously. Visualize a simple

case in a piping system where during design, a reducer in a pipeline is moved from one block to

another. This would materially change the pipe length requirements for the different diameter

pipes. As the BOM process involves rollup for multiple piping systems throughout the ship, this re-

calculation of the BOM would become an arduous task in the file/part-based hierarchical approach.


4.4.3 Change, Impact, Analysis, and Management

In a network, a small, seemingly insignificant change can have major material impact. Changing

a pressure or temperature in a process flow sheet can change bore size of a piping network and

installed mechanical equipment such as valves, pumps, instruments, the BOM, weight, center of

gravity, and so on. Assessing the impact of these potential changes before they are approved is

made substantially easier by having the ability to traverse and analyze a connected network of

related objects. Isolating the changes in data domains and managing the inconsistencies ensure

there are no surprises as the fabrication evolves.

But a ship or marine structure is not wholly a topological network. Hull forms, mechanical

equipment, and structural members are also representative of traditional assemblies. Therefore,

the cPLM system needs to manage a hybrid of topological networks and hierarchical assemblies.

SmartMarine Enterprise is designed to support both of these, integrated together, and present them

to users in a uniform way to optimize learning and familiarization.

4.5 Integrated Disciplines vs. Digital Mock-up

File/part-centric design systems rely on DMU technologies to assemble and view the entire, multi-

discipline product from the multiple constituent parts (files) in the PLM system. These DMU

systems either utilize a single common format (proprietary systems such as JTOpen or industry

standards such as ISO10303 STeP) for the file or have the ability to open multiple formats from

multiple vendors. The DMU software analyzes the location/coordinates/scale and assembly

connectivity to present the user with a real-life view. However, as indicated in the previous

discussion, any interrogation of the data for these parts is entirely dependent on the rendering

capability of the source system and the data scope of the receiving file format (with, of course,

any mapping/transformation in the middle).

Tasks such as interference detection, 2D/3D analysis, measurement, cross-sectioning, and

comparison in a file/part-centric system are all after-the-fact exercises, whereas in a data-centric,

multi-discipline database, these functions are available as an integral part of the design process.

The Smart 3D technology of the SmartMarine Enterprise is a multi-discipline, data-centric design

system which enables all these tasks without the need for a post-design DMU application. It is a

live, active DMU that does not require reassembly or post-processing of the separate files.


4.6 Configuration Management for Derivatives vs. Variants

As indicated in Section 3.3, experienced design in cPLM is about deriving new configurations

by reusing or re-purposing existing designs. In some cases, this means defining a “mother ship”

as a template and deriving dissimilar “sister ships” from this baseline, such as removing blocks,

adding different equipment/outfitting, or altering specific parameters. In other cases, it may mean

deriving a ship using a mix-and-match approach from a fleet of designs. However, in either case,

the resulting ship will be a unique configuration in its own right.

This derivative approach is different to the variant approach in PLM for discrete manufacturing,

where the designer attempts to satisfy many different customer and market needs from a

palette of options. In this case, each option or alternative is part of the same basic structure.

The different variations of the product can be viewed by manipulating the option/alternate

relationships between the objects in the PLM system.

SmartMarine Enterprise supports configuration management of derivates where the hull

applicability is managed in the tools. Design changes are fed between the tools and each

configuration is separate and unique. Yet, there is the ability to query across multiple

configurations. This is necessary to understand the baseline from which a new derivative

is to be established and to determine the unique differences.


5. Conclusion

Intergraph’s SmartMarine Enterprise is a next-generation cPLM designed solely for shipbuilding,

marine, and offshore structures. It is not a re-purposed, discrete manufacturing CAD/CAM/PLM

solution like those currently available on the market – Siemens/Teamcenter, Dassault Systemes/

ENOVIA, AVEVA/OpenPLM (recently renamed AVEVA NET), PTC/Windchill, and others.

Intergraph is the only vendor to offer a cPLM system based on the concepts described in this

white paper, which better fit the shipbuilding and marine industries.

SmartMarine Enterprise is totally data-centric, where the deliverables are reports and renderings

of the database. It is open by design and provides cPLM characteristics:

Data sharing

Managed inconsistency

Topological networks

Integrated disciplines

Configuration management for derivatives

Its unique Smart3D technology, used for the physical configuration of the marine facility, is

multi-discipline and performed against a single database with no limitations in terms of numbers

of objects or numbers of concurrent users (see Section 4.1 Data-centric vs. File/Part-centric). It

provides rule-based automation (based on a patented “associativity” methodology) that is able to

boost the design-to-production process by capturing and utilizing industry standards and company-

specific know-how. Global workshare further opens Smart3D to accommodate remote and partner

collaborative ship development.

SmartMarine Enterprise integration, such as between functional (2D) and topological (3D)

applications (e.g., schematic P&ID with 3D outfitting arrangement), manages and promotes

consistency during design, not the “check afterwards” approach required by non-integrated

systems. Similarly, application and data integration with major applications, such as nesting,

enterprise resource planning, and scheduling, position SmartMarine Enterprise as the next-

generation cPLM for shipbuilding, marine, and offshore industries.

For more information about Intergraph,

visit our Web site at www.intergraph.com.

Intergraph, the Intergraph logo, SmartMarine, and

SmartPlant are registered trademarks of Intergraph

Corporation. Other brands and product names are

trademarks of their respective owners. Intergraph

believes that the information in this publication is

accurate as of its publication date. Such information

is subject to change without notice. Intergraph is not

responsible for inadvertent errors. ©2009 Intergraph

Corporation. All Rights Reserved. 08/09 PPM-US-

0081A-ENG

http://www.intergraph.com/

Date post:	13-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

IMGS White Paper Template - Process, Power and Marine · So, what is cPLM, and how is it different...

Documents