Software, services, and expertise for the business of shipbuilding.

        • Achieve a Quick ROI
        • Sliced implementations and our expertise means a benefit from day one, without a lengthy setup.

        • Integrate, Collaborate, Re-use
        • SSI’s Open Shipbuilding Platform gives you a future-proof source of truth for your shipbuilding projects.

        • Change Management
        • Get visibility into changes, understand the impacts, and have the right information at the right time to execute the change.

        • Adapt and Innovate
        • Create a local or virtualized shipbuilding environment for your global distributed workforce.

        • Changing from Another Solution
        • SSI makes it easy to switch from other platforms and keep your existing data.

        • Design
        • The most significant opportunities to impact the cost of building and operating a ship are found in the design and engineering phase.

          Initial Design  |  Basic Design  |  Detailed Design

        • Build
        • Even a smaller shipbuilding project is immense in scope and scale. Manage the challenges that are unique to ship construction.

          Prepare  |  Fabricate  |  Assemble

        • Maintain
        • With the majority of a ship’s life taking place after it’s been built, it’s crucial to ensure that the organization has a clear picture of the vessel at all times.

          Digital Twin  |  Repair / Refit  |  Operations

        • Nexus
        • SSI Nexus is a community for users, creators, & implementers of SSI software.

        • SSI Certified Training
        • SSI Certified Training allows SSI users to access detailed training exercises, materials, courses, and certifications.

        • SSI Blogs
        • The SSI blogs are your place to get insights from our CEO into the intersection of shipbuilding and technology, see how shipbuilding is moving forward, and keep up with SSI news.

          Lighthouse Waveform  |  Shipbuilding Solutions

        • ShipConstructor
        • A complete line of solutions for the design, engineering, and construction of ships and offshore projects.

        • EnterprisePlatform
        • Tools to connect and share data across every system in the shipyard and make information available.

        • ShipbuildingPLM
        • The only truly shipbuilding-specific product lifecycle management (PLM) platform.

        • Company
        • Learn more about SSI and our leadership.

        • Locations & Contact
        • You need a partner with a global presence.

        • News
        • The latest on SSI and shipbuilding.

        • Events
        • Join us at our next event, conference, or trade show.

        • Partners
        • Learn more about our Platform and Development Partners.

        • Clients
        • See the industry leaders who trust SSI.

        • Careers
        • Help us make the business of shipbuilding possible.

November 17, 2015


I am sure many of you are familiar with Model Based Enterprise (MBE) and Model Based Definition (MBD).  I explain MBD as a Technical Data Package (TDP) which contains all the information (3D Model, 3D/2D Views, annotations, PMI, GD&T, etc.) needed to accomplish one’s task. Using this TDP over traditional 2D Drawings and various other files is definitely better but I always felt that using any sort of disconnected uncontrolled “package” limits the full potential of collaboration. I even wrote about it in one of my previous blog posts Model-Based Enterprise Summit 2014. However, when I started to think of the MBD not as a file based package but as a representation of your product definition it really expanded my thinking that for a Model Based Enterprise you do not need to have any files or “packages” whatsoever.

Why did I Think a Filed Based Package was Required?

The Model Based Enterprise website defines MBD:

The Model Based Enterprise (MBE) is made up of many related processes. At its core is the product definition which we refer to as the Model Based Definition (MBD). Another way to define MBD is an annotated 3D CAD Model that contains all the information needed to define a product. This annotated model replaces a traditional drawing. Thus, a drawing is created by exception not as a standard process.

It says nothing about file based Technical Data Package (TDP) or capturing your product definition in a file. It does refer to a model but a model does not necessarily require a file. However, when you look at the page How MBE Works it states:

During the production stage the annotated product model must be effectively communicated to the supply chain. This is done through the 3D Technical Data Package (TDP).

This TDP will be delivered digitally through a supplier portal linked to the OEM’s PLM or ERP tool

In this definition I interpreted package as a file based package. I think this is not necessarily correct.

I do not think I was alone in this thinking since at several conferences and summits I have attended mostly everyone talked about MBD by using files such as JT, 3D PDF, STEP, etc. These conferences and discussions strengthen the idea that files are required for any MBE. I do not recall anyone talking about a MBD or MBE environment without files, or at least I was too blind to see it.

What Changed

After reading a blog post by Ed Lopategui I realized that my concept of MBD being a file based package was incorrect. He talked about the lost potential opportunity of new modern cloud CAD+ providers which did not support a model based representation and are instead going backwards by supporting 2D drawings. The idea that a pure cloud solution can provide a MBD without files was what really started me down the path of realizing that a MBD does not need to be a file.

The main reservation I had with MBD which I have mentioned in previous blog posts is that with most MBE environments you are sending a snapshot file based technical data package. It does have much better information than a 2D drawing which means you can communicate efficiently with less misinterpretations but it does not facilitate improved collaboration and is susceptible to the same issues of “what is the latest version?” I know you can use an enterprise system to store the MBD which will ensure you always get the latest release, but the idea that the primary data is still in a snapshot file based package is my main issue.

However, if the MBD is not required to be file based, that opens up many possibilities of communicating the contents without relying on native applications which need to be installed to view the package contents.

Why does this matter

Many companies are investing or have invested in an enterprise solution(s) that contain all or most of the information produced and consumed. These solutions usually contain files but also have features to display the contents of those documents without a requirement of sending files. For example, these solutions show you the contents of pdf, doc, dwg, JT, etc. without the requirement of downloading any files. They even can display an interactive view which allows you to interact with the data with just a browser.

If we combine the fact that MBD is just a representation and the fact that these enterprise solutions can represent data as well as allow you to interact with it, then there is the potential to have a solution where we do not need to pass the TDP but the solution still satisfies all MBD requirements. These solutions can provide representations of the data for each stakeholder with only the information that is needed for that user, exactly what an MBD was supposed to do.

This solves the two main problems I had with MBE:

  1. We no longer need to pass proprietary files packages containing open file standard files (eg. STEP) which requires us to download a free viewer to view the data.
  2. We can actually collaborate on the data since we do not need to pass files back and forth which I loathe as a method of collaborating

I totally understand that files are still required for some of the end stakeholders and that that is not going to change. Fortunately, if they are needed, I note that a file based package can be generated by the system and then downloaded if/when necessary. However, the requirement for files should not be overstated. There are many activities such as review that not only can be done without files, it is better to not use them at all. Modifying a model is a better because it allows a means of collaborating and not just communicating.

Here is an example of a MBD package which is generated and always up-to-date. In this representation there are no tolerances or dimensions because the were already handled upstream. There are three views which you can cycle through at the top.You can select items and get its properties as well.

Closing Remarks

Model Based Enterprise is definitely gaining in popularity which means there is much more information relating to it. I luckily came across Ed’s blog which opened my eyes and allowed me to realize that the limitations I thought were related to MBE were actually a limitation of my interpretation of the actual implementations not the methodology.

I am not saying that we should implement MBE without any file based technical data packages, just that we can.

By lifting the constraint of files in MBE I see new potentials for virtual reality or augmented reality which will be the representation of the data. However, this does mean that there may need to be an update to the following description:

 At its core is the product definition which we refer to as the Model Based Definition (MBD). Another way to define MBD is an annotated 3D CAD Model that contains all the information needed to define a product.

I would really like your comments and thoughts as I evolve my thinking.

Post Comments

  1. Bruno Benevolo says:

    Denis, excellent post and Ed Lopategui certainly has some interesting/controversial blog posts:)

    I will divide my post in two parts: Part 1 – Crystal Ball Fun, Part 2 – Down-to-earth stuff.

    Part 1. Crystal Ball Fun

    Will MBD/MBE kill the 2D drawing within shipyards?

    I think there is a general consensus that MBD/MBE will become a standard in most discrete manufacturing industries especially for those with a high level of production automation, 3D Printing has opened up the possibility of almost frictionless communication from the 3D design model to the manufacturing process and will be certainly a big driver for MBD/MBE adoption.

    As we all know shipbuilding manufacturing is still a semi-automated, generally engineer-to-order industry and still requires human interference in the assembly, advanced outfitting phases, for example. We already see 3D design review terminals on the shop floor in many shipyards, but for some of the human input tasks, production staff still require 2D drawings. Depending on the skill level of your production floor, often the 2D drawing needs to have a huge amount of additional dimension information and text information to communicate correctly to shop floor staff what needs to be done, and this generates a massive overhead in Engineering having to post-process 2D drawings automatically generated from a 3D model, especially when you undertake any revision of the 3D model. I think one of the main points for MBD/MBE adoption in shipyards is being able to get sufficient data into the 3D model and improving production floor skill sets so that no post-processing of 2D drawings extracted from the 3D model is required.

    Tablets are still seen as too delicate for use during the execution of many of the manufacturing tasks within the shipbuilding production environment and I don´t see that changing any time soon. Perhaps electronic flexible screen technology, if sufficiently robust and cheap enough, could be a next step, allowing production staff to carry 3D live/online TDPs around and lay them down on the floor, fix them up on walls etc? As soon as the 3D model is changed and approved in engineering a notification can be read instantly warning the user of what has changed. I can see augmented VR glasses being an interesting option for QA/inspection staff having to review production progress on the shop floor, comparing the real world model with the TDP. It will be interesting to see whether these new “bleeding edge” technologies are used in the future to present a live, always updated, 3D TDP within the shop floor environment.

    My long term (scary) view of MBD/MBE in Shipbuilding:

    Another aspect that could be looked into that might be a game changer for MDB/MBE adoption in shipyards is the wide-use of intelligent tags (if they become cheap enough) offering orientation/positioning info that can be read on all parts so you can track a given part from stock to the assembly and then use tag readers which can determine the 3D location of the part as well as its orientation withing a given block & quickly determine whether every part has been inserted correctly in for a given block, comparing this information with the 3D TDP. The tags would have to be pretty robust to be adopted for shipyard production processes!

    If we look at the (scary) wave of advanced adaptable robotics in the next 30 years I can see shipbuilding production environments where the engineering drawing is certainly completely dead/ex-parrot/ceased to be etc:). A flow of information from the 3D model direct to production via MBDs (without the need for any 2D drawing sets) with robots executing the majority of the manufacturing process reading the 3D TDP online and using as reference factory location sensors as well as tag data on parts to execute tasks with frightening repeatable precision!

    Part2. Down-to-earth stuff.

    Change Management for Shipbuilding within the MBD/MBE context.

    Coming down to earth with some present day challenges:) Within the MBD/MBE context, we can start looking at TDP datasets as being specific ” 3D bounding boxes” of the overall Ship 3D model, with associated 2D documents, representing within a given product hierarchy/WBS what needs to be executed and what resources/materials are required to execute a given phase of the shipbuilding process. As soon as you revise the 3D model, you will need to determine which 3D/2D TDP datasets have been impacted by the 3D model change, probably requiring some ECO process to approve that change, using a PDM/PLM system to manage the change and guarantee a synced delivery of the 3D /2D TDP to Production.

    As stated in Part 1 above, one of the key items here which will determine the speed/efficiency of the change management/ECO process is whether the 2D part of the TDP requires additional work/information after a post 3D model generation phase, requiring a checking process of the 2D documentation and not just the 3D model subset. Another point to note is that sometimes what needs to be revised is just the 2D post-process content and not the 3D part of the TDP and the PDM/PLM system will need to understand that sort of revision process as well.



Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.