This blog post is the first of a two part series. This post will form an introduction and in the second post I will dig into the concepts in more detail and specifically from a ShipConstructor perspective.
During a few recent trips to clients, potential clients, and SMM in Hamburg we engaged with several people who are either using, or will potentially use, our technology exclusively for basic design (concluding with a classification package as the penultimate deliverable). This isn’t new to SSI or our customers but it isn’t something we put front and center very often.
Clients who are focused on basic design, whether that model will carry forward or not, have different challenges and a different set of requirements than those focusing exclusively on detail design or production engineering. Let’s dig into some of those:
- Change – Change is a constant in all aspects of ship design and construction. As you get closer to the earliest stages of the process, fewer parameters of the design are fixed. This results in both more constant change, and changes that have larger impacts on more of the overall design.
- Direct Cost – Early stage design can have a very significant impact on both cost of engineering and cost of production, and perhaps an even more significant impact on cost of operation and maintenance. However it is an activity far removed from those costs, and one often performed by a different organization than the one responsible for these later tasks. While reduced cost downstream due to increased use of a 3D model, more accurate drawings, and improved quality of drawings don’t entirely fall on deaf ears they are almost always a very distant second to a desire to decrease direct man hours.
In a previous post I touched briefly on the latter of the two points. In this post I want to focus mostly on the first: Change
In the earlier design phases the types of changes encountered are typically macroscopic, as opposed to the more detailed (but sometimes still broad in their impact) changes that occur once the design moves into the detail phase. Examples of these macroscopic changes include changes to the hull form/shape, changes to frame spacing, bulkhead, deck and longitudinal locations, broad changes to overall scantlings and more…
These changes at first glance seem deceptively simple. When they cascade throughout a 3D product model, and to associative drawings, they are in fact very complex. Not surprisingly the mechanisms to handle these changes in CAD software are as complex and as varied as the changes they are intended to help users make. There are a number of different approaches. There are other classification systems or ‘buckets’ that could be used but I would put most systems into one of these major types:
- Script or macro based approaches – Typically seen in shipbuilding specific applications these systems rebuild the model from an underlying set of scripts or macros on demand. The model is not changed so much as it is rebuilt when change is required.
- Parametric modelers – Typically seen in generic CAD applications. The model is defined in terms of a number of parameters, usually expressed in terms of the dimensions of other geometry or objects. The parameters are reevaluated as changes occur.
- Associative models – Typically found in industry specific applications these models are usually defined by an associative topology of standards and geometry. This topology can be based on parent-child relationships in which case changes cascade from the top down, or sibling-sibling relationships in which changes can propagate from one sibling to any others in a network fashion.
- Hybrid – Typically seen in both general and industry specific tools these applications combine a number of approaches. ShipConstructor, for example, is largely an associative modeling tool, but has a number of parametric relationships with offsets, distance along construction lines, and dimensions of certain standards.
As important as the type of modeling software is the philosophy behind how change is intended to be managed by that system (two software packages of the same type can be very different in execution based on this ‘little’ detail), as well as how the modeling engine is actually typically employed by users. I’ll cover these two areas from a ShipConstructor perspective in my next post.