The SFI Group System: a functional classification for ship technical data, its limits and its future

SFI was developed in Norway in the early 1970s by Skipsteknisk Forskningsinstitutt, the Ship Research Institute of Norway, whose initials give the system its name. Its original purpose was to give shipyards, owners and suppliers a common structure for ship specifications and cost information, so that a newbuilding could be specified, priced and compared system by system. Maintenance, spare parts and document management came later, as owners carried the specification structure into operations.

That origin matters. SFI was designed to answer the question "what does this part of the ship do, and what does it cost?" It was not designed to answer "where is it?", "what kind of equipment is it?" or "which serial-numbered unit is fitted?" Each of those questions has become important in the digital era, and each is the source of a recurring difficulty with SFI that later sections examine.

The system is now maintained and licensed commercially. Fleets should use a licensed, versioned edition and record which edition their data follows.

SFI is a decimal, enumerative hierarchy. Each additional digit narrows the scope:

The eight main groups are:

Figure 1. Anatomy of an SFI code. The first three levels are standard and shared across the industry; the detail level is defined by each user, which is where interoperability is usually lost.

Two design choices deserve attention. First, the split between main group 6 (machinery main components) and main group 7 (the systems that serve them) separates components from systems: a main engine sits in one place, its fuel, lubricating oil, cooling and starting air systems in another. Second, main group 8 gathers ship-wide services such as electrical, ballast and bilge, and fire-fighting systems that serve many consumers. Both choices reflect a functional, system-engineering view of the ship rather than a physical or spatial one.

Information science distinguishes several ways of organising things. Placing SFI among them explains both its strengths and its limits.

Enumerative versus faceted classification

An enumerative scheme lists every class in a single fixed hierarchy; each item has one place. A faceted scheme describes items by combining several independent dimensions, such as function, type, material and location. SFI is enumerative. That makes it easy to learn, easy to print in a specification and easy to roll up into totals, which is exactly what specification and cost work requires. The price is that any property not built into the single hierarchy has to be represented somewhere else, or not at all.

Mutually exclusive, collectively exhaustive

For costs to add up correctly, a breakdown must be mutually exclusive (nothing counted twice) and collectively exhaustive (nothing left out). SFI is designed to meet both conditions at the levels it standardises, which is why it works well for budgets, specifications and cost reporting by system.

Kind-of versus part-of

Hierarchies can express two different relations: "is a kind of" (taxonomy) and "is a part of" (partonomy, or composition). SFI's upper levels are mainly functional groupings; at the detail level, users typically build a part-of hierarchy (equipment, then components). Many PMS databases blur the two, so that a code sometimes means "the fuel system" (a system the item belongs to) and sometimes "a fuel pump" (a kind of item). Reliable analytics depend on keeping these relations distinct, a point section 7 returns to.

Functional versus physical decomposition

Systems engineering separates the functional breakdown (what the system must do) from the physical breakdown (what hardware does it) and the spatial breakdown (where the hardware is). SFI is primarily functional. That is its great advantage for comparing ships: two vessels with different layouts and different makers' equipment can still be compared function by function.

SFI is one of several established schemes. Each was designed for a different purpose.

Three observations follow.

1. SWBS and SFI are close relatives in principle. Both are functional, system-based hierarchies designed originally for design, weight and cost. Experience with SWBS in naval logistics shows the same pattern as with SFI in commercial PMS: the functional code works well for specification and cost, and needs additional structures for maintenance and supply.
2. IEC 81346 makes explicit what SFI leaves implicit. It treats function, product and location as separate aspects, each with its own designation, so that one object can be found through any of them. This is the conceptual answer to most of SFI's limitations.
3. ISO 14224 and ISO 19848 cover what SFI does not. ISO 14224 defines what kind of equipment something is and how it fails; ISO 19848 defines how its data is named. Neither replaces SFI; both complement it (see our white paper on equipment hierarchies and master data).

Most of the difficulties fleets experience with SFI fall into six categories. None is a flaw in the sense of an error; each is the consequence of a single functional hierarchy being asked to do more than it was designed for.

5.1 Shared equipment and multiple function

Many items serve more than one function. A general service pump may supply fire-fighting, bilge and ballast duties; a compressor may serve both starting air and service air. An enumerative scheme forces each item into a single place, so the choice is a convention, and conventions differ between ships and between the people who build the data. The result is that the same equipment type appears under different codes across a fleet, and fleet-level analysis splits.

Mitigation: fix the convention at fleet level (for example, "code shared items under the system of their primary duty") and record the secondary functions as relationships, not as duplicate equipment records.

5.2 Cross-cutting systems

Electrical power, automation and piping run through every other system. A motor driving a cooling water pump is part of the cooling system functionally, part of the electrical system as a consumer, and connected to the automation system for control. A single code cannot express all three, so information is either duplicated or hidden.

Mitigation: code the item once under its primary function and hold the electrical and control relationships as links (feeder, starter, control loop), as IEC 81346 does with its separate aspects.

5.3 Location is not represented

SFI does not say where an item is. Two identical pumps in the same system can only be distinguished by numbering at detail level, and a crew member cannot find either from its code. Planning, permit-to-work, inspection rounds and digital twins all need location.

Mitigation: add a separate location structure (deck, compartment, frame range) as its own attribute or hierarchy, not as digits inside the SFI code.

5.4 Equipment type is not represented

The SFI code of a purifier identifies its function in the fuel or lubricating oil system; it does not identify it as "a centrifugal separator of maker X, model Y". Comparing all separators across a fleet, or applying one maker's service letter to every affected unit, requires an equipment class and model dimension.

Mitigation: add an equipment class (ISO 14224 style) and a controlled maker and model reference to every record.

5.5 Detail-code divergence

The first three levels are standard; the detail level is not. Each yard, owner and PMS supplier extends SFI differently, and the same owner's ships built at different yards often arrive with incompatible detail structures. This is the single largest cause of non-comparable data in fleets that believe they "use SFI".

Mitigation: define a fleet detail-code standard with templates per equipment class, and map each vessel to it when it joins the fleet or migrates PMS (see our white paper on PMS data migration).

5.6 Version drift

Like any maintained standard, SFI has editions. Ships coded to different editions may use slightly different titles or placements for the same function. Without a recorded edition, it is impossible to know whether two codes truly mean the same thing.

Mitigation: record the SFI edition in the fleet data standard and keep a mapping when moving between editions.

The six limitations share a solution: keep SFI as the functional aspect and add the other aspects alongside it, linked to the same object. This is the principle behind IEC 81346, applied to a ship PMS.

Figure 2. One object, four aspects. SFI answers "what does it do?"; the equipment class, the location and the physical asset answer the questions SFI was never designed for.

In such a model, the PMS functional location is identified by its SFI code (plus a fleet detail code), carries a location and an equipment class, and has a physical asset installed in it. Jobs, measurements and failures can then be attached at the right level: maintenance tasks to the functional location or equipment class template, failures and overhaul history to the physical asset, and condition data to measurement points defined on the equipment.

The benefits are concrete:

• Fleet analytics can group by function (cost per SFI group), by equipment type (reliability of a given model) or by asset (history of a rotable), from the same data.
• Maker campaigns can be applied to every unit of a model regardless of where it sits in the SFI tree.
• Crews and planners can find equipment by location.
• Digital twins and sensor data (see The future of PMS) can link 3D models through location and data channels through ISO 19848 identifiers, while maintenance stays organised by SFI.

As maintenance data feeds analytics, AI tools and twins, the meaning of a code matters as much as its value. Three practices keep SFI data semantically sound:

1. Separate relation types. Record explicitly whether a link means "belongs to system", "is part of" or "is a kind of". Ambiguous parent-child links are the main reason automated analysis of PMS hierarchies produces misleading results.
2. Use controlled vocabularies for every aspect. Makers, models, equipment classes, locations and failure codes should come from reference tables, never from free text.
3. Version the reference data. When a code's meaning changes, the history must show which meaning applied when.

These principles align with wider work on industrial data, including ISO 8000 on data quality and ISO 15926 on the integration of life-cycle data, which treat classification and identification as part of data quality rather than as clerical detail.

1. Adopt a written fleet SFI standard: edition, depth, detail-code rules, conventions for shared and cross-cutting equipment.
2. Hold the other aspects separately: equipment class, maker and model, location and serial number as their own fields, never encoded inside the SFI number.
3. Build templates by equipment class and model, each placed at its standard SFI position, and create vessel data from them.
4. Map every ship on entry to the fleet standard, whether it comes from a yard, another manager or another PMS.
5. Assign a data owner who approves new codes, conventions and mappings under management of change.
6. Measure conformance: share of equipment coded to the fleet standard, records missing location or equipment class, and duplicates across codes.

SFI's endurance is not an accident. A stable functional breakdown is precisely what a ship-owning organisation needs to specify, budget and compare vessels over decades, and no alternative has displaced it in commercial shipping. The pressure on SFI comes from new uses: sensor data, fleet reliability analytics and digital twins all need location, equipment type and physical identity as well as function.

The likely path is therefore not replacement but composition: SFI as the functional backbone, combined with equipment taxonomies, location structures, asset registers and standardised data identifiers in a multi-aspect model. Fleets that organise their data this way gain the comparability SFI was designed for and the analytical power the digital era demands.

The SFI Group System is best understood as a functional classification designed for specification and cost, successfully extended into maintenance. Its limitations (shared equipment, cross-cutting systems, missing location and equipment type, detail-code divergence and version drift) are the predictable limits of a single enumerative hierarchy. They are resolved by adding aspects, not by abandoning the code: keep SFI for function, and hold type, location and asset alongside it under clear governance.

• Skipsteknisk Forskningsinstitutt (Ship Research Institute of Norway), SFI Group System, and the current licensed edition.
• IEC 81346 series, Industrial systems, installations and equipment and industrial products — Structuring principles and reference designations.
• ISO 14224, Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment.
• ISO 19848, Ships and marine technology — Standard data for shipboard machinery and equipment.
• Naval Sea Systems Command (NAVSEA), Expanded Ship Work Breakdown Structure (ESWBS).
• ISO 15926 series, Integration of life-cycle data for process plants including oil and gas production facilities.
• ISO 8000 series, Data quality.
• Companion papers: 05 Equipment hierarchies and master data, 03 Migrating PMS data and 07 The future of PMS.

Applying SFI coding to your fleet? We design fleet SFI standards, detail-code templates and multi-aspect master data, and map each vessel to them. See our Planned Maintenance System services.