In Part 1 of this 3 post series (ok, I know I said it was going to be 2 parts but this one ended up being longer than I expected) I talked a bit about the realities of the basic design process and how software tools can help make that process easier. I promised to talk in Part 2 about how SSI philosophically approaches ‘change’ (regardless of the particular phase in the process) and how our clients approach the creation of an ideal ShipConstructor product model to ease the management of change earlier in the design process. In my next two posts I will endeavor to do both of those things.
Philosophy of Change
Change is both one of the more common and more daunting things to deal with in the design and construction of a ship. In other industries like discrete manufacturing (think equipment, consumer products, small assemblies) the scale and scope of the end products allows a high degree of predictability when change propagates throughout a product model. Due to the comparatively lower complexity, not only can the rules (parametric, topological or associative) be built into the model more easily, the resulting change is easier to validate. However, even in these industries as the models become more complex many designers find it very difficult to work within a model created by others (either due to poorly created models, the difficulty of understanding the rules that another user built into their model, or both).
Shipbuilding makes this challenge many times worse as the scope and scale of our projects exceeds that of almost any other industry. The enormity of our projects also makes tools that can automate and manage change even more valuable. Sound familiar?
Our philosophy has always been to allow and encourage automated change, but in such a way that the user can view, control, and understand the results of the change before it happens. The first example of this, going back more than 13 years in some of our products, was the associative DWG production drawings that could be updated automatically as the model changes. With the current versions of ShipConstructor all drawings can be automatically updated as the model changes. We use language like “can be automatically updated” rather than “are automatically updated” as the user is told which drawings need to be updated, has control over when that update takes place, and is completely informed as to what will be changed in the drawing, who made the changes and when they occurred, before the drawing is changed.
This same philosophy was applied when the modeling portion of ShipConstructor was rewritten a number of years ago. Newer versions of ShipConstructor (ShipConstructor 2008 and later) have associative and parametric relationships between many items in the product model. Part 3 of this series will discuss the nature of these relationships in more detail.
With the depth of potential relations that can be created in such a system, SSI believes that it is critical that no changes occur automatically without the informed consent of the user making the change and the ability to control the impact of any change before it occurs. To contrast this, some other tools make these changes automatically and then leave the user(s) to validate the change absent information about what was changed. ShipConstructor shows the impact of a change to the user across the product model before it happens, and allows the user to limit the impact of the change only to items or areas they choose.
In the next, and final post in this series we will look in detail at the relevant capabilities that exist in our product model and how users are working with them.