by Ícaro Aragão Fonseca – Exchange Student in Ship Design / Høgskolen i Ålesund
(email@example.com), v1.1, Dez 2014.
SFI is a widely used classification system for ships, oil platforms and other maritime structures. The SFI system allows its users to divide hierarchically the elements inside a maritime structure for a wide range of purposes related to control of shipping, offshore or shipbuilding operations.
By splitting the ship into different systems and sub-systems, the user (e.g. a shipyard or ship design company) is able to keep track of costs, working-hours, materials, maintenance, information, etc. of each functional aspect of a ship in detail, as should be seen in the next sections.
To allow that kind of hierarchical division, SFI introduces a code structure including group, sub-group and detail codes, each of them related to a certain degree of detail or system size. Therefore, it is possible to carry on the control of every element inside a ship by simply associating that element to a 6-digit code. Most of the SFI structure is standardized, thus facilitating information exchange, collaborative work and design.
For example, let us suppose that we want to identify a ship’s main diesel engine inside the SFI classification system. The detail code for that component is 601001, where main group 6 encompasses “Machinery main components”, group 60 includes “Diesel engines for propulsion”, sub-group 601 includes “Diesel engines” and, lastly, the full detail code 601001 is assigned to the “Main diesel engine” itself.
In this report, we will present the SFI for some components of a multipurpose offshore vessel as an example of the classification system and then we will propose a data structure to represent that classification in a hypothetical digital database.
- Availability of powerful object oriented features embedded.
- Accessible language with functionalities easily shared via internet.
- Easy implementation of visualization features with public libraries.
Where the first point is especially important for our work at this stage, since we want to create an efficient structure to represent one vessel as a JS object. Our choice for this kind of data structure was driven by the following main reasons:
- JS objects are capable of handling large amounts of data, which would be necessary to store information about a ship’s systems, parts and documentation.
- JS objects allow easy handling and accessing of data through their properties.
- JS objects’ properties are versatile and can store text strings, numbers and other kinds of variables. They can as well store functions (methods) or even other objects in them.
The JS object structure aimed at this report should be able to store information about a ship’s systems and components, including name, SFI code, working hours and cost. Let us suppose, for example, that the user wants to access the information about the cost of the main diesel engine. Then, he could simply call for a value inside the object’s property, or:
During the next sections and Appendix 2, we will go into detail about the object structure and how it can be used to store and handle SFI data.
Below is presented the methodology flowchart followed by detailed explanation of each step:
- Collect/compile relevant information: gather all available relevant information about the ship and its systems, such as equipment model, material costs, person-hours, drawings and technical analysis. This could be either self-generated information such as the drawings and technical analyses or previously available information, like equipment model, specifications or costs. The SFI classification system can as well be applied to systems during design or building stages, giving the user a system-based view of the choices made during design and assisting with planning and control of the building process, for instance. This is not the case with this project, however, and we assume all the information to be available beforehand.
- Identify systems involved or mentioned: identify the systems mentioned on the collected information and analyze how they fit the SFI hierarchical listing structure. Identify the system with the higher possible amount of detailing inside SFI.
- Identify SFI code: in the SFI listing catalog, search for the correspondent id code to each system, subsystem or element whose information was gathered. Assign a main group, group, subgroup or detail code to the system or product.
- Register information with id codes: register the same information, this time with a systematical approach based on SFI. List each system with its respective id code.
Applying the methodology
As an example of the SFI coding scheme, in this project we applied the methodology to a commercial catalog of a multipurpose offshore vessel. Most of the information available about the ship’s systems concerned to basic equipment specifications and identification of the manufacturers, so it was not possible to include detailed technical information about them. Anyhow, it was still manageable to categorize the described systems according to the SFI structure, which was the main objective of the work. At the end of the classification (step 4.), we obtained a table with all the information registered in the catalog, the corresponding SFI name for each of the systems and their respective identification codes.
Ship.SFI=new SubGroup(“Rotating cranes with crane pillars”,300);
Ship.SFI=new DetailCode(“Rotating cranes with crane pillars: GPOKac 5000-135-30”,500000);
Where 300 is the number of working-hours and 500.000 is the price.
Then, the structure automatically calculates the results of those two values for any asked level of the classification hierarchy (Sub Group, Group and Main Group), so the user can know what are the most time and capital consuming systems of the vessel according to the SFI classification. The user can access those values inside the .cost and .hours properties of the objects:
This is part of the classification table obtained at the end of step 4.:
The information about the equipment was listed in the lowest possible level, preferably the detail code. When there was not sufficient information about one system to associate it to a detail code, then the available information was listed in the group or sub-group level, such as in the last line, where it was not possible to assign a detail code to the vessel’s module handling system. In some cases, there were two or more components assigned under the same detail code, such as the four main diesel engines or the two different rotating cranes (see table above). In order to distinguish the different components, we added one identification number after the detail code, e.g.: 33100101/33100102, where 331001 is the detail code and 01/02 are the component identification numbers.
Although we reserved some fields for cost and working hours records, those data were not available and therefore were filled with placeholders. The full table with the catalog information listing is available on Appendix 1.
At the end of this work, we have an incipient SFI classification for a multipurpose offshore vessel. Even if the amount of information and the coverage of that classification is extremely limited, it sets the base for other applications with a wider coverage of a ship’s systems, more technical and commercial information, etc.
Starting from this project, we try to keep those applications allied to digital systems to handle relevant information about the vessel so we can maximize the convenience and overall benefits of the SFI classification system.
Next steps of this work would be to apply systems engineering concepts to study the relation between a modular ship concept and the SFI group system. We intend to create a mapping between conceptual modules of a ship and the related SFI groups. With that mapping, we would be able to analyze to which extent the exchange of one or more given modules influences the overall SFI group system for one vessel.
Appendix 1 – Example of SFI based on commercial catalog
Instructions: the SFI object has 4 levels: MainGroup (e.g.: Ship.SFI) Group (e.g.: Ship.SFI), SubGroup (e.g.: Ship.SFI), and DetailCode (e.g.: Ship.SFI). At each one of those levels, there are properties to store information about name, cost (material costs) and person-hours, except for the DetailCode level, which does not have a property to store person-hours information (since this data is registered starting from the SubGroup level).
Each object was created with one of the constructors defined inside the script. In all constructors, you should enter the input “name”. In addition, in the DetailCode level, you should also enter the cost of the part/product, and in the SubGroup level, the amount of working hours. By default, all values in the script are zero, but the user is free to change them if he wants. To access the cost information at the detail code level, add .cost after the DetailCode, for example: Ship.SFI.cost. To access hours information in the sub-group level, add .hours after the SubGroup, for ex.: Ship.SFI.hours. At any level of the structure, it is possible to call for the system name adding .name after the object, for ex.: Ship.SFI.name or Ship.SFI.name.
Now let’s see how the structure updates its values. Run the code on the console. Then, add cost values for some detail codes belonging to the same sub-group, for example:
If you want to access one of the stored values, you can type:
Now, if you want to access the total value of the Ship.SFI sub-group, you can digit:
And it automatically returns the sum of the values we inserted into the two detail codes. The same thing works for the higher levels of the structure, for example, do:
If you want now to check the total cost of the Ship.SFI group, just call:
And the structue returns the sum of all costs listed under that hierarchical level, i.e., the three detail codes you fulfilled until now. Please note that the parenthesis are necessary, since this time you are not simply calling a value, but a function that calculates the total cost based on the costs from the lower hierarchical levels.
But what if you want to input the cost value in a level other than the detail code? In this case, just insert the value at the desired level, for example:
So, the value 100 is stored in the .cost property of the sub-group Ship.SFI. However, there are some consequences: when you do that: you are substituting the function that updates the cost for a numerical value, which means that the structure will not update itself automatically anymore until that level of the hierarchy. In other words, even if you do:
the console will keep returning 100 when you call:
Notice also that since you manually entered a number into the .cost property, when you want to call that property again, you should not use the parenthesis anymore.