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.
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 i
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 1
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
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 2
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 3
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 4
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 5
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 6
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?”
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 7
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
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 8
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 9
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, applicationneutral 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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 10
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 11
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 12
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 13
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’ “yellowlining” squad check.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 14
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-ofquantity, 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).
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 15
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 recalculation of the BOM would become an arduous task in the file/part-based hierarchical approach.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 16
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, multidiscipline 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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 17
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.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 18
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 companyspecific 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 nextgeneration cPLM for shipbuilding, marine, and offshore industries.
cPLM vs. PLM for the Shipbuilding, Marine, and Offshore Industries
Page 19
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-US0081A-ENG