This recent post on the necessity of open architecture in software tools and the upcoming release of our first product in the SSI EnterprisePlatform product line has made me think a lot about information. In particular, I think it is a worthwhile exercise to think about how, where, when and why information is created and used in shipbuilding.
Looking at general-purpose CAD software, there has been an overwhelming push towards parametric 3D modelers over the last decade. Recently we’ve seen products incorporating mixed parametric and direct modeling, and even new products, like Autodesk Fusion 360, that were originally launched with only direct modeling capability. However, no matter how they get there, the result is a 3D CAD model.
How is this relevant to us? Well, this type of software is one of the two classes of CAD software generally in use in the shipbuilding industry. This isn’t my soapbox for how well (or not) general parametric modelers scale to very large ship models, especially if the model in question isn’t a large commercial vessel with a parallel midbody stretching over 80% of the ship (ok maybe a small soapbox). However the reality is that this type of software has secured a place in the industry and needs to be considered. The key takeaway when looking at products in this category in the context of information is that result of the modeling phase is a 3D model.
The other, and frankly still much more common at least in medium and larger yards, general category of CAD software in use today was born specifically for shipbuilding. The goal and result of the modeling phase (whether that be via direct modeling, a rule based engine, or scripting) isn’t a 3D model of a ship, it is a virtual model of a ship. The model is complete with contextual information, including the form and function of each portion of the model. For example, a stiffener knows that it is a stiffener, knows that it is attached to a plate, and creates marking information on that plate in the model via that association.
I’m not saying that one approach is inherently better than another. As ShipConstructor belongs to the latter group I have an obvious bias. However what I’m interested in is the impact that this has on information.
In the second approach a lot of the production, material, and other information required in downstream processes is available in the model. In the first, it is often inferred during the creation of drawings or the transmission to PLM products. That difference can have a pretty profound impact on implementation and selection of tools and processes around the CAD product.
Open Architecture
Our CTO’s post was about the inevitability and benefit of open architecture platforms. While I wholeheartedly agree that any and all information should be available, the depth of information available in a product largely determines the value of accessing the information that product has to offer. If a CAD product contains the 3D geometry but all other information needs to be inferred or accessed in another product entirely (a PLM product for example) then the value of an open architecture in the CAD product alone is reduced. If the information exists in other tools, including PLM tools, then it is more valuable to ensure the selection of PLM tools with an open architecture. It also means that the purchase and implementation of a PLM tool is required to leverage that sort of information, even for smaller organizations.
3rd Party Integration
Another area that is very much impacted by the location and availability of information is when integrating with other processes and tools. Where the information is determines where the integration must take place. More importantly perhaps, if the information is inferred from the model, the integration method must also be capable of inferring that information.
PLM
No conversation about information in shipbuilding would be complete without at least mentioning PLM. At many of the conferences we attend (ICCAS, COMPIT etc…) there is always at least one paper about the lower adoption rates of PLM in shipbuilding. The truth is, everyone has a “PLM solution” and the challenges that require one. However a smaller number of shipbuilders have truly purchased and implemented PLM products.
I believe the types of tools used and information generated in shipbuilding are a large part of the reason why PLM tools are not routinely implemented, with the exception perhaps of the mega-yards. The tools most commonly used in shipbuilding, those in the ‘shipbuilding-specific’ category outlined above, generally combine the extra information that exists in the model with tools to manage that information. Those products contain at least some capabilities to manage change to drawings and BOMs derived from the model and tools to manage the change to the model itself. The boundary between a PLM product and this type of CAD product is less clearly defined than the boundary between a general CAD modeler and a PLM product. Conversely the value of a traditional PLM product in this scenario is lower or at least less well understood.
In an organization with products of the first type, those that are more focused on parametric 3D modeling, a separate (even if from the same vendor) PLM product can be implemented to manage the model, BOMs, drawings and change. If implemented properly with the selection of an open architecture, easy to use and implement PLM tool the two solutions can be functionally very similar.
Conclusions
There are a lot of conversations taking place in the industry around CAD/CAM products, PLM products, information flow and accessibility of that information. Shipbuilders rightly want to leverage more and more of the information that is generated through the design and construction of a ship. However many of these conversations are had (and decisions are made) in isolation. In fact they are often made by different departments and decision makers. The conversations being had include: What CAD product should I use and how will I integrate it? Should I look to PLM? What MRP/ERP product should I use to manage production and the rest of my organization? How do I communicate with other departments? With the exponential growth in the depth and breadth of information being created in a shipyard, and the explosion in choice and capabilities of tools available to shipyards any answer to one of these questions can have profound impacts on the others. The questions being asked (and the answers from vendors like SSI) need to transcend the traditional departmental, functional and information-based silos and look at the bigger picture.