CIS/2 vs IFC for steel: when to choose each

The problem that starts every steel handover argument

It is Tuesday afternoon. The structural analysis team has just finished a 47-story tower frame in RISA-3D. They need to send the analytical model to the connection-design group, who will take it into RAM Structural System, run group-design checks, and pass the shaped-up model to the detailer in Tekla Structures. The analysis team manager opens the export dialog. There are two rational choices: CIS/2 or IFC. She picks CIS/2 because that is what she has always done and because the RISA documentation says it transfers "nodes, element connectivity, section profiles, loads, material properties, forces and displacements" natively.

Across town, the integrator responsible for the BIM coordination model is having a different conversation. He needs to merge the structural steel model with the MEP clash surfaces, the architectural shell, and the facade consultant's geometry — all inside a federated Navisworks session that will be reviewed by the owner's representative on Thursday. He needs IFC. He does not need load cases. He does not care about the pin-release flags at beam ends. He needs the right section sizes, the right systemline elevations, and the right material grades in the properties panel so the owner can interrogate the model during their BIM Execution Plan review.

Both of these people are right. The analysis manager is right to reach for CIS/2. The integrator is right to demand IFC. The mistake — the one that has burned weeks on dozens of projects — is letting one team make the format decision for both. CIS/2 and IFC are not competing answers to the same question. They are answers to different questions, and understanding which question you are actually asking is the whole game.

This post exists because the "just use IFC for everything" camp and the "CIS/2 is the only real steel format" camp both cause real project damage. If your coordination model is being produced from a CIS/2 file that went through NIST's SteelVis translator, connection geometries are silently missing. If your analysis software is trying to reconstruct releases and load combinations from an IFC 4.3 physical model file, you are building a castle on sand. The format must match the receiver, not the sender's habits.

We will walk through both formats in technical depth, build a side-by-side comparison across the dimensions that actually matter on projects, identify the anti-patterns that keep showing up in real workflows, and close with two case studies where choosing deliberately made a measurable difference. There is also working code for parsing both formats, because the fastest way to understand a data model is to read it.

CIS/2 in depth

Origins and stewardship

CIMsteel Integration Standards Release 2 — universally shortened to CIS/2 — was conceived in the late 1990s at the University of Leeds and the Steel Construction Institute in the United Kingdom. The immediate catalyst was the observation that structural steel projects involved an enormous volume of hand-keyed re-entry: geometry modeled in design software was being retyped into analysis software, then retyped again into detailing software, then retyped into fabrication management systems. Each re-entry step introduced errors and consumed billable time.

The technical lead on the American side was Chuck Eastman at Georgia Tech, who later became one of the founding theorists of building information modeling. Eastman and his collaborators recognized that steel had a property that made it unusually tractable for data-model standardization: it is a discrete, catalogue-driven material. An AISC W21x68 is an AISC W21x68 everywhere. There is no equivalent of "custom masonry unit with variable coursing" in structural steel. The member library is finite and well-defined. That made a shared schema achievable.

The American Institute of Steel Construction adopted CIS/2 as its official structural steel data exchange format in 2000 — one of the earliest formal endorsements of a neutral exchange format by a major engineering trade body. NIST (the National Institute of Standards and Technology) took on the stewardship role that matters most to practitioners: NIST developed and maintains SteelVis, the reference CIS/2 viewer and translator, and published the authoritative academic work on the CIS/2-to-IFC mapping through Robert Lipman's research program. SteelVis version 8.92, released in 2022, remains the canonical validation tool for CIS/2 files.

AISC has since shifted its formal interoperability strategy toward IFC. But that shift is at the policy and marketing level, not at the toolchain level. The actual software that steel fabricators and structural engineers use in 2026 — RISA-3D, RAM Structural System, GT STRUDL, SDS/2 — still speaks CIS/2 as its primary neutral format, and will for the foreseeable future because the installed base of these tools in North American practice is enormous.

Technical foundations: EXPRESS, STEP Part 21, and the three model levels

CIS/2's technical foundation is ISO 10303, commonly called STEP (Standard for the Exchange of Product model data). The schema is written in EXPRESS, the Part 11 data modeling language defined in ISO 10303-11. The physical file encoding follows STEP Part 21, the clear-text encoding standard that produces files with a .stp extension and a recognizable header-data-end structure.

CIS/2 also borrows from STEP Part 42 for geometric primitives: coordinate systems, points, and curves. This is a deliberate choice that keeps the geometry portion of the schema aligned with an ISO-standardized vocabulary rather than inventing new geometric entities.

The schema defines three distinct model levels, each appropriate for a different phase of the steel workflow:

Level 1 — Analysis model. Nodes, element connectivity, section profiles, loads, material properties, and analysis results (forces, displacements). This is the format that RISA, RAM, GT STRUDL, and ETABS trade in. Load cases, load combinations, and member end releases are first-class citizens here.

Level 2 — Design model (drawing model). Physical representation with materials, member geometry including cardinal point, camber, orientation, member-to-member connections in broad terms (pinned, moment, etc.), and steel grade. This is the model that moves from analysis into detailing software.

Level 3 — Fabrication/detailing model. Fully detailed geometry including copes, blocks, rats, web penetrations, weld definitions, bolt group layouts, hole patterns, piecemark assignments, and CNC-ready manufacturing data. SDS/2's CIS/2 export operates at this level; it can include gather sheets, detail sheets, and DSTV-format CNC files as attachments to the Part 21 file per the AISC EM11 Phase 2 specification.

This three-level architecture is one of CIS/2's most important design decisions. A Level 1 file from RISA carries exactly what the analysis software knows: nodes, bars, profiles, loads, results. It carries nothing it does not know. There is no fiction of bolt details or weld sizes that have not been designed yet. The file honestly represents the current state of knowledge. This is the correct approach for analysis-phase exchange.

EXPRESS schema: a working fragment

Here is a representative fragment of the CIS/2 EXPRESS schema showing how a structural member is typed and how its cross-section connects to STEP Part 42 geometry. This is illustrative — the full schema runs to several thousand lines — but it conveys the data model's character:

-- CIS/2 EXPRESS schema fragment (illustrative)
-- Based on CIMsteel Integration Standards Release 2 / STEP Part 11 (ISO 10303-11)
 
SCHEMA cimsteel_integration_standards_2;
 
  REFERENCE FROM geometry_schema (axis2_placement_3d, direction, cartesian_point);
  REFERENCE FROM product_definition_schema (product_definition);
  REFERENCE FROM measure_schema (length_measure, mass_measure, plane_angle_measure);
 
  -- -------------------------------------------------------
  -- Section profile: maps directly to AISC section tables
  -- -------------------------------------------------------
  ENTITY cs_material_profile_section;
    section_type    : cs_section_type_enum;    -- e.g. W_SHAPE, HSS_ROUND, ANGLE
    section_name    : STRING;                  -- e.g. 'W21X68', 'HSS6X6X1/2'
    cardinal_point  : cs_cardinal_point_enum;  -- 1-15 per AISC convention
    is_mirrored     : BOOLEAN;
  END_ENTITY;
 
  -- -------------------------------------------------------
  -- Analysis member: the Level 1 workhorse
  -- -------------------------------------------------------
  ENTITY cs_member;
    member_id       : INTEGER;
    member_type     : cs_member_type_enum;     -- BEAM, COLUMN, BRACE, TRUSS_CHORD, etc.
    start_node      : cs_analysis_node;
    end_node        : cs_analysis_node;
    profile         : cs_material_profile_section;
    material_grade  : cs_steel_grade;          -- e.g. A992, A500_GrC, S355
    start_release   : cs_end_release;          -- pin/fix/partial per DOF
    end_release     : cs_end_release;
    orientation     : axis2_placement_3d;      -- borrowed from STEP Part 42
  END_ENTITY;
 
  -- -------------------------------------------------------
  -- Analysis node: the geometric anchor
  -- -------------------------------------------------------
  ENTITY cs_analysis_node;
    node_id         : INTEGER;
    coordinates     : cartesian_point;
    restraint       : OPTIONAL cs_nodal_restraint;  -- support conditions
  END_ENTITY;
 
  -- -------------------------------------------------------
  -- End release: member DOF conditions (6 DOF per end)
  -- -------------------------------------------------------
  ENTITY cs_end_release;
    ux : cs_release_condition;    -- translation X: FIXED | FREE | SPRING
    uy : cs_release_condition;
    uz : cs_release_condition;
    rx : cs_release_condition;    -- rotation X
    ry : cs_release_condition;
    rz : cs_release_condition;
  END_ENTITY;
 
  -- -------------------------------------------------------
  -- Load case: named grouping of applied loads
  -- -------------------------------------------------------
  ENTITY cs_load_case;
    load_case_id    : INTEGER;
    description     : STRING;                  -- 'DEAD', '1.2D+1.6L', etc.
    load_type       : cs_load_type_enum;
    loads           : SET [1:?] OF cs_load;
  END_ENTITY;
 
END_SCHEMA;

The physical STEP Part 21 file wraps instances of these entities in a DATA section between ISO-10303-21; and END-ISO-10303-21; delimiters. Every instance is keyed by a sequential #n reference. A real excerpt for a single W-shape member looks like:

/* CIS/2 STEP Part 21 physical file excerpt */
ISO-10303-21;
HEADER;
  FILE_DESCRIPTION(('CIS/2 Analysis Model','Structural Steel Frame'),'2;1');
  FILE_NAME('tower_frame.stp','2026-05-30T14:22:00',('J. Smith'),
            ('BIM Mobius Engineering'),'SoftwareApp v12.0','','');
  FILE_SCHEMA(('STRUCTURAL_FRAME_SCHEMA'));
ENDSEC;
 
DATA;
  /* Coordinate points */
  #10 = CARTESIAN_POINT('',(0.0, 0.0, 0.0));
  #11 = CARTESIAN_POINT('',(0.0, 0.0, 4572.0));  /* mm, 15 ft story height */
 
  /* Section profile: W21x68 at cardinal point 5 (centroid) */
  #20 = CS_MATERIAL_PROFILE_SECTION('W21X68',
        .W_SHAPE.,           /* section_type */
        'W21X68',            /* section_name  */
        .CP5.,               /* cardinal_point: centroid */
        .FALSE.);            /* is_mirrored */
 
  /* Steel grade: A992 Fy=50ksi */
  #21 = CS_STEEL_GRADE('A992', 345.0, 448.0);  /* Fy MPa, Fu MPa */
 
  /* Nodes */
  #30 = CS_ANALYSIS_NODE(1, #10, $);            /* free node */
  #31 = CS_ANALYSIS_NODE(2, #11, $);
 
  /* End releases: both ends fixed (moment frame column) */
  #40 = CS_END_RELEASE(.FIXED.,.FIXED.,.FIXED.,.FIXED.,.FIXED.,.FIXED.);
  #41 = CS_END_RELEASE(.FIXED.,.FIXED.,.FIXED.,.FIXED.,.FIXED.,.FIXED.);
 
  /* The member itself */
  #50 = CS_MEMBER(101,              /* member_id  */
        .COLUMN.,                    /* member_type */
        #30, #31,                    /* start / end node */
        #20, #21,                    /* profile, grade */
        #40, #41,                    /* releases */
        #AXIS_PLACEMENT_REF);        /* orientation */
ENDSEC;
END-ISO-10303-21;

Software support in practice

The following table reflects verified support as of mid-2026. "Native" means the vendor ships and maintains the translator as part of the core product without requiring third-party plugins.

The "via S3D plugin" note for Tekla deserves explanation. Tekla's documentation for CIS/2 in 2024 and 2025 routes the functionality through the Smart 3D Interoperability plugin available from Tekla Warehouse. This means CIS/2 is not a direct Tekla export in the same sense that IFC is; it requires the intermediary plugin. In workflows where Tekla is the detailing tool and RISA or RAM is the analysis tool, the SDS/2-to-RISA path via CIS/2 is often more reliable than the Tekla path precisely because SDS/2's CIS/2 implementation is mature and covers Level 3 fabrication data.

IFC steel scope in depth

The architecture of IFC and how steel fits

IFC (Industry Foundation Classes) is a different kind of standard than CIS/2. Where CIS/2 was designed from the start for one material, one supply chain, and one set of software categories, IFC was designed as a common data model for the entire built environment. It covers architecture, structural engineering, MEP, facilities management, civil infrastructure, and now — with IFC 4.3 — roads, bridges, railways, and ports.

IFC 4.3 was approved as ISO 16739-1:2024 on January 4, 2024, receiving 100% approval from ISO member bodies. The current stable schema version is IFC 4.3.2.0 (often written IFC4x3). Tekla Structures 2025 holds buildingSMART International certification for IFC2X3, IFC4, and IFC4.3 export.

The structural steel domain in IFC is not a separate sub-standard. It is a collection of entities, predefined types, and property sets within the main IFC schema. Understanding where steel lives in the IFC type hierarchy is the prerequisite for understanding what the format can and cannot express.

Core entities for structural steel

IfcMember is the primary entity for any structural member whose function does not map cleanly to IfcBeam (horizontal, gravity) or IfcColumn (vertical, gravity). The IFC documentation defines it as "a structural member designed to carry loads between or beyond support points," explicitly noting that orientation is irrelevant to the definition. This makes IfcMember the natural home for braces, kickers, struts, truss chords, and any other member that structural engineers would call a "force member" rather than a gravity member.

In Tekla Structures, members sloped between 20 and 70 degrees are automatically exported as IfcMember regardless of the IFC entity setting chosen in the model. This is default behavior, not a configuration bug. Downstream tools must therefore be able to handle the same logical steel member appearing as IfcBeam, IfcColumn, or IfcMember depending on its inclination and the export settings used.

IfcBeam and IfcColumn carry the horizontal gravity framing and vertical gravity framing respectively, with PredefinedType enumerations (BEAM, HOLLOWCORE, JOIST for beams; COLUMN, PILASTER for columns) to further qualify the element.

IfcPlate covers flat steel plates: gussets, base plates, shear tabs, capping plates, stiffeners, and similar non-prismatic elements. This is a heavily used entity in connection-heavy steel models.

IfcMechanicalFastener (IFC4.3.2 schema reference: 6.3.3.9) represents mechanical fasteners "connecting building elements or parts mechanically." A single instance can represent an array of fasteners. The PredefinedType enumeration includes: ANCHORBOLT, BOLT, COUPLER, RAILFASTENING, RAILJOINT, ROPE, and the catchall USERDEFINED. For structural steel bolting, the BOLT predefined type is used with the Pset_MechanicalFastenerBolt property set, which carries NominalDiameter, BoltGrade, ThreadLength, and head/nut geometry parameters.

IfcDiscreteAccessory (IFC4.3.2 schema reference: 6.3.3.3) covers discrete components added to structural elements: brackets, shoes, rail braces, tensioning equipment, and connection hardware that does not classify as a fastener. In steel connection modeling, column base shoes, flange stiffeners treated as discrete accessories, and hold-down brackets map here.

IfcBoltElement — this entity name circulates in practitioner discussions but it is not a top-level IFC 4.3 entity. The correct entity is IfcMechanicalFastener with PredefinedType = BOLT. Practitioners who encounter "IfcBoltElement" in documentation are likely reading IFC 2x3-era informal usage or software-specific naming conventions.

Property sets relevant to steel

Pset_ProfileArbitraryHollowSection, Pset_ProfileArbitraryDoubleSymmetricShape: These carry cross-section geometry parameters when the profile cannot be expressed by a named catalogue entry.

Pset_StructuralProfileItem: The property set for analytical member properties. Carries YoungModulus, PoissonRatio, ThermalExpansionCoefficient, MassDensity, and YieldStress. This is the bridge between the IFC physical model and structural analysis properties.

Pset_MechanicalFastenerBolt: Thread diameter, nominal length, bolt grade (ASTM A325, A490, ISO 8.8, 10.9), head type, nut type.

Pset_ElementComponentCommon: Shared across all element components. Carries Reference (mark), Status, and CorrosionTreatment.

IfcMaterialProfileSet + IfcMaterialProfileSetUsage: The canonical IFC mechanism for associating a cross-section profile with a linear member. The profile can reference a named standard section (IfcIShapeProfileDef, IfcCShapeProfileDef, IfcRectangleHollowProfileDef, etc.) or a custom parametric shape. This is the IFC equivalent of CIS/2's cs_material_profile_section entity.

IFC STEP encoding for a steel column

/* IFC 4.3 STEP Part 21 physical file excerpt */
/* Illustrating an IfcColumn (W14x82, A992, moment frame) */
 
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0]'),'2;1');
FILE_NAME('structural_steel_tower.ifc','2026-05-30T14:22:00Z',('J. Smith'),
          ('BIM Mobius'),
          'Tekla Structures 2025','','');
FILE_SCHEMA(('IFC4X3_ADD2'));
ENDSEC;
 
DATA;
/* --- Material: A992 structural steel --- */
#100 = IFCMATERIAL('A992 Steel',$,$);
#101 = IFCMATERIALPROPERTIES('Pset_StructuralProfileItem',$,
        (#102,#103,#104,#105),#100);
#102 = IFCPROPERTYSINGLEVALUE('YoungModulus',$,
        IFCMODULUSOFELASTICITYMEASURE(200000000000.),$);  /* 200 GPa */
#103 = IFCPROPERTYSINGLEVALUE('PoissonRatio',$,
        IFCPOSITIVERATIOMEASURE(0.3),$);
#104 = IFCPROPERTYSINGLEVALUE('MassDensity',$,
        IFCMASSDENSITYMEASURE(7850.),$);                  /* kg/m3  */
#105 = IFCPROPERTYSINGLEVALUE('YieldStress',$,
        IFCPRESSUREMEASURE(345000000.),$);                /* 345 MPa = Fy 50 ksi */
 
/* --- Cross-section: W14x82 as IfcIShapeProfileDef --- */
#200 = IFCISHAPEPROFILEDEF(.AREA.,'W14X82',$,
        177.8,             /* OverallWidth  mm  */
        358.1,             /* OverallDepth  mm  */
        13.1,              /* WebThickness  mm  */
        22.1,              /* FlangeThickness mm */
        0.,$,$,$);
 
/* --- Material profile set --- */
#210 = IFCMATERIALPROFILE('W14X82',
        'Wide-flange column section',#100,#200,$,$);
#211 = IFCMATERIALPROFILESET('W14X82 A992',$,(#210));
#212 = IFCMATERIALPROFILESETUSAGE(#211,.AXIS2.,$);
 
/* --- Geometry: placement along vertical axis --- */
#300 = IFCCARTESIANPOINT((0.,0.,0.));
#301 = IFCCARTESIANPOINT((0.,0.,4572.));      /* 15 ft story height, mm */
#310 = IFCAXIS2PLACEMENT3D(#300,$,$);
#311 = IFCLOCALPLACEMENT($,#310);
 
/* --- IFC column entity --- */
#400 = IFCCOLUMN('3dNhGfP8v2ZO9aXFt1k5jW',  /* GlobalId (base64 GUID) */
        $,                                     /* OwnerHistory     */
        'COL-A1',                              /* Name             */
        'W14x82 Moment Frame Column',          /* Description      */
        $,                                     /* ObjectType       */
        #311,                                  /* ObjectPlacement  */
        $,                                     /* Representation   */
        'COL-A1',                              /* Tag              */
        .COLUMN.);                             /* PredefinedType   */
 
/* --- Associate material profile with member --- */
#410 = IFCRELASSOCIATESMATERIAL('2mPQrTz9xY...',$,$,$,(#400),#212);
 
/* --- Structural properties via Pset --- */
#500 = IFCPROPERTYSET('7kLhMW...',$,
        'Pset_StructuralProfileItem',$,(#102,#103,#104,#105));
#501 = IFCRELDEFINESBYPROPERTIES('8nVjPQ...',$,$,$,(#400),#500);
 
ENDSEC;
END-ISO-10303-21;

IFC 4.3 enhancements relevant to steel

IFC 4.3 (ISO 16739-1:2024) brought several improvements that matter for structural steel exchange:

Infrastructure extensions: While primarily aimed at civil engineering, the infrastructure domain additions include new alignment and cross-section capabilities that are relevant to bridge steel and curved structural members. Steel pedestrian bridges and highway overpasses now have a more complete semantic home.

Improved IfcAlignment and IfcPositioningElement: These affect how curved steel members in curved-plan structures are positioned. Previously, curved steel in IFC was geometrically correct but semantically thin.

Revised IfcFacilityPart hierarchy: For building structures, this is largely transparent. For projects where the structural steel model spans building and civil (a stadium with a cantilevered roof truss over a road, for example), IFC 4.3's unified hierarchy is the first version that can accommodate the model without artificial splits.

Refined IfcMechanicalFastener types: The RAILFASTENING and RAILJOINT predefined types were added in IFC 4.3, reflecting the infrastructure expansion. For building steel, the BOLT and ANCHORBOLT types are the relevant additions.

Side-by-side comparison

This is the longest section of the post for a reason. The format decision is almost never about which standard is "better" in the abstract. It is about which format carries the data the receiver needs, in a form the receiver's software can consume, without introducing plausible but wrong data in the fields the receiver will actually use.

What each format captures cleanly

Detailed data element mapping

The table below captures how specific data elements travel through each format. "Native" means the format has a first-class entity or attribute for the concept. "Via Pset" means the data can be attached as a property set but is not a structural schema entity. "Drop" means the format has no representation for the concept and it will be silently omitted. "Reconstruct" means a receiving tool must infer the value algorithmically from other data, introducing potential error.

The word "Drop" in this table is the most important word to understand. It does not mean the data was corrupted. It means the format has no slot for it and a compliant reader will simply not produce any value for that field. The danger is silent: the receiving tool typically fills the missing field with a default value (zero, fixed, or "unknown"), and the engineer downstream may not notice unless they check systematically.

What each format loses — or manhandles

This is where the real decisions get made, so it deserves more prose than a table.

What CIS/2 loses going outward

CIS/2's export from Tekla via the S3D plugin transfers the analysis model faithfully, but in a typical Level 2 export the rich connection geometry that Tekla has modeled — extended end-plates, moment end-plates, shear tabs with specific slot patterns, field-welded connections — is not in the file in a form that receiving analysis software can directly consume. Those details live in the Level 3 fabrication model, and Level 3 exports are not universally supported or consumed.

More critically, there is no reverse path. NIST's own documentation for SteelVis states explicitly: "No reverse translators exist — there is no IFC-to-CIS/2 or VRML-to-CIS/2 conversion capability." If your process requires taking a federated IFC model and pushing structural updates back into a CIS/2-native analysis tool, you have a manual re-entry step. This is the most common CIS/2 workflow failure mode on collaborative projects.

CIS/2 is also a one-domain format. If the project scope expands to include concrete, precast, or MEP elements in the structural envelope (as happens on composite structures), those elements have no home in CIS/2. The format will either omit them or require a parallel IFC model for coordination, which immediately raises the question of why CIS/2 is being used at all for the coordination deliverable.

What IFC loses going outward

IFC's most significant loss for structural analysis workflows is the semantic precision of the CIS/2 analysis model. The IFC structural analysis entities (IfcStructuralCurveMember, IfcStructuralSurfaceMember, IfcStructuralLoadGroup) exist in the schema but are only populated when the exporting software explicitly constructs the analytical model — which is a different model object from the physical model in most IFC implementations.

In a standard Tekla-to-IFC export, you get the physical model: 3D geometry, profiles, materials, properties. You do not get the analytical model with load cases and reactions unless the exporting workflow explicitly includes it. A structural engineer receiving a Tekla IFC file and expecting to push it directly into RISA or RAM without reconstruction is going to be disappointed.

Load cases and load combinations are not natively first-class citizens in an IFC physical model. They can be expressed via IfcStructuralLoadGroup and related entities in the analytical model schema, but support for those entities in analysis-targeted import tools is inconsistent at best.

Member end releases in IFC are carried by IfcStructuralCurveMemberVarying and connection boundary conditions — entities that require the analytical model schema, not the physical model schema. In practice, releases are almost always lost when transferring between physical IFC and analysis tools unless both ends of the exchange explicitly support IFC structural analysis view.

The coordination model perspective

For multi-discipline coordination, IFC is the only rational choice. CIS/2 carries no architectural or MEP data. There is no mechanism for a CIS/2 file to participate in a Navisworks or Solibri clash-detection session that includes the ductwork model. The workflow is: CIS/2 for analysis, IFC for coordination. This is not a preference — it is a capability boundary.

Section naming: the silent compatibility risk

One practical compatibility issue that deserves its own discussion is section naming across geographies. CIS/2 uses AISC section designators as the canonical section name string. A W21x68 is "W21X68" in a CIS/2 file exported from any North American tool. When that file is imported into a European tool that references the Eurosteel or British Steel section catalogue instead of AISC, the importer may not find "W21X68" in its own catalogue, substitute a "nearest equivalent," or simply fail to assign a section.

The reverse is equally true. A CIS/2 file from a European tool carrying "HEA 200" in the section name field will confuse a North American analysis tool that only knows AISC W, M, S, HP, and HSS shapes. The CIS/2 specification allows any string in the section name field, which means cross-catalogue compatibility is entirely dependent on both tools knowing the same naming convention.

IFC handles this more robustly for parametric sections. IfcIShapeProfileDef carries dimensional properties (OverallWidth, OverallDepth, WebThickness, FlangeThickness) directly. A receiving tool that cannot find the section by catalogue name can fall back to the parametric dimensions and construct the section from scratch. This fallback path does not exist in a CIS/2 Level 1 file where the section is only identified by a name string.

For projects that span geographies — a US owner, a European structural engineer, a North American fabricator — this section naming issue is a practical workflow problem that requires an explicit mapping table in the project's data management plan. Neither format completely solves it, but IFC's parametric fallback makes it more gracefully recoverable.

Connection design data: the gap neither format fully closes

Here is the honest gap in the current state of the art: no neutral exchange format handles connection design data — the detailed geometry of a bolted moment connection, the weld sizes on a shear tab, the stiffener plate arrangement on a column web — in a way that is routinely consumed by both analysis and fabrication tools from a single file.

CIS/2 Level 3 from SDS/2 carries this data in fabrication-ready form, but it is not consumed by analysis software for design verification — the analysis tools read CIS/2 Level 1 and ignore the Level 3 connection entities. IFC carries bolts via IfcMechanicalFastener and plates via IfcPlate, which is sufficient for coordination-level spatial check (is there room for the bolt group between this beam web and the ductwork?) but does not carry the connection design parameters that RAM Connection or Tekla Connection Designer needs (design forces, weld throat, bearing length, slip-critical vs. bearing).

The practical resolution in current workflows is: connection design lives in the connection design software (RAM Connection, Tekla Connection Designer, IDEA StatiCa) and is validated there. The output of the connection design phase enters the detailing model (Tekla, SDS/2) and then leaves as fabrication data. Neither the CIS/2 nor the IFC file is the authoritative source of connection design intent during the design phase — only after the detailing model has been updated with the connection designer's outputs does either format carry reliable connection geometry.

This is a gap that the industry is actively working on. IDEA StatiCa's integration with Tekla and its Open Model API is one current approach to bridging design and detailing without a neutral format intermediary. buildingSMART's IFC working groups have discussed enhanced connection entities for several IFC development cycles. But as of mid-2026, practitioners should plan around this gap rather than assume either format eliminates it.

Round-trip fidelity

The round-trip test — export from software A to format F, import into software B, re-export back to format F, reimport into software A, compare to original — reveals more about a format than any specification document.

Robert Lipman's NIST research (published in the Journal of Information Technology in Construction, 2009, Volume 14) found that the CIS/2-to-IFC mapping "identified several deficiencies in the IFC schema for modeling structural steel and for general structural analysis models." The mapping from CIS/2 to IFC produced one-to-one correspondences for many entities but one-to-many and one-to-none mappings in others. In the one-to-none cases, CIS/2 data was simply dropped. This work was done against IFC 2x3; IFC 4.3 has closed some of those gaps but not all.

For CIS/2 round trips within the CIS/2 ecosystem (RISA → RAM → RISA), fidelity is generally high for Level 1 data. Section names round-trip cleanly because both tools reference the same AISC section database. Load cases round-trip if both tools support the same load type enumeration, which is almost always true for standard load types (DEAD, LIVE, WIND, SEISMIC) and less reliable for user-defined or custom load types.

For IFC round trips in the physical model space (Tekla → Revit → Tekla), the geometry arrives intact but semantic attributes — Tekla-specific properties, connection component data, assembly hierarchies — are lost at the Revit boundary and cannot be reconstructed. This is not an IFC deficiency; it is a consequence of Revit having a different native data model and not being able to store connection-level Tekla attributes in its own schema. The IFC did its job; the round-trip loss is at the receiving application boundary.

The IfcBeam → IfcMember reclassification problem deserves specific mention as a round-trip hazard. Tekla Structures automatically exports beams sloped between 20 and 70 degrees as IfcMember (treating them as braces) even when the element was modeled and tagged as IfcBeam in the Tekla model. A downstream tool that uses the IFC entity type to drive classification logic — for example, an automated quantity take-off tool that counts IfcBeam instances vs. IfcMember instances separately — will produce incorrect results unless it accounts for this behavior. The fix (available since Tekla 2022) is to explicitly set the IFC entity type in the Tekla property pane before export. But if a model was exported without that override, a round-trip from IFC back into Tekla will produce elements that Tekla classifies differently than the original model intent.

Analysis workflows: CIS/2 wins

For the analysis team, the choice is almost always CIS/2, and the reasoning is straightforward. Analysis software — RISA, RAM, GT STRUDL, STAAD.Pro — was built around a workflow where you have a wireframe model with profiles, grades, load cases, and releases. That is exactly what CIS/2 Level 1 carries. The CIS/2 import dialog in RISA-3D maps directly onto what a structural engineer thinks of as "the model": nodes, members, sections, loads, supports. No geometric reconstruction. No interpretation of extrusion solid bodies back into analytical centerlines. No guessing whether a 3D brep is supposed to be a pinned-ended brace or a moment-connected rafter.

The RAM Structural System's CIS/2 export documentation describes the payload as "geometry, end-fixities, and shapes" — which is precisely what the downstream detailer needs to begin the connection design process. GT STRUDL goes further: it can create a CIS/2 analysis model file containing all import data plus analysis results, enabling a complete analysis-package handover via a single file.

The RISA CIS/2 translator documentation confirms that the format allows transfer of "not only the wireframe but other member information like member properties, material properties, member orientation, member end conditions like releases, support conditions, loading information" — a data set that no IFC physical model export reliably provides in a form that analysis tools can directly consume.

GT STRUDL's bidirectional CIS/2 support is worth calling out as the most complete analysis-focused implementation. GT STRUDL can both import a CIS/2 analysis model and export one that includes analysis results — forces, moments, displacements — alongside the structural model data. This enables a workflow where GT STRUDL is the analysis engine, produces a CIS/2 file containing the completed analysis, and that file is consumed by a downstream connection design or detailing tool that needs both the geometry and the design forces in a single package. No other common analysis tool produces this "results-inclusive" CIS/2 export as a standard feature.

ETABS and SAP2000 have historically supported CIS/2 for analysis model exchange, though CSI's recent interoperability focus has shifted toward their direct integrations (the ETABS-Tekla link, ETABS-Revit direct sync) and toward IFC for third-party exchanges. The CIS/2 path in ETABS is described in CSI documentation as "legacy" in some versions, which is a signal that teams relying on ETABS-to-RISA CIS/2 exchange should test their specific version combination before committing it to a project workflow.

STAAD.Pro's CIS/2 import — documented by Bentley — reads a CIS/2 file and populates the STAAD model with nodes, members, sections, and supports. STAAD's export to CIS/2 is similarly supported. Given that STAAD.Pro is widely used in India, Southeast Asia, and the Middle East alongside Tekla Structures for detailing, this combination (STAAD as analysis, Tekla as detailing, CIS/2 as the exchange format between them) is a common workflow pattern in those regions.

Coordination workflows: IFC wins

For the coordination model — the model that the owner reviews, that the clash detection runs against, that the quantity surveyor interrogates, that the facility manager receives at handover — IFC is the only choice that works at scale. The reasons are cumulative:

1. Every discipline produces IFC. The architectural model (Revit or ArchiCAD), the structural model (Tekla or Advance Steel), the MEP model (Revit MEP or MagiCAD) can all be exported to IFC and federated in Navisworks, Solibri, or BIMcollab. CIS/2 cannot participate in this federation.

2. Tekla's IFC export carries rich semantic data. The "Renewed IFC Property Set Definitions" introduced in Tekla Structures 2024 produce standardized, buildingSMART-certified property sets on every element. An owner receiving the IFC file can query ProfileName, Material, FinishCode, PieceMark, and dozens of other attributes through any IFC-aware tool.

3. IFC 4.3 is the current ISO standard. Owner BIM Execution Plans in European public procurement now routinely specify IFC 4.3 as the handover format. Contractors and fabricators who cannot deliver IFC 4.3 are excluded from those procurement processes.

4. IFC supports structural bolt connections via IfcMechanicalFastener, which means a coordination-level review can verify bolt group presence and approximate location relative to MEP clearances — a use case that CIS/2 Level 1 simply cannot address.

Fabricator preferences: the split between North America and the rest of the world

This is where the regional dimension matters. The split between CIS/2-preferring and IFC-preferring fabricators is real, geographically coherent, and has practical consequences for project workflows.

North America: The established North American steel fabrication supply chain grew up with CIS/2. AISC endorsed it in 2000 and the major North American analysis and detailing tools — RISA, RAM, SDS/2, STAAD.Pro — all have mature, tested CIS/2 implementations. A fabricator receiving a CIS/2 Level 3 file from SDS/2 gets piecemark data, DSTV CNC files, gather sheets, and ABM page-line identifiers in a single handover package. IFC at fabrication level does not yet deliver this in a form that North American shop management systems can directly consume.

The SDS/2 2026 release notes are instructive: the significant interoperability announcement was "enhanced IFC exports with enriched welding data, including robotic layout nodes" and direct upload to BIMPLUS — not a new CIS/2 capability. SDS/2 is investing in making IFC more fabrication-ready, which signals the direction of travel, but CIS/2 remains the primary fabrication exchange format for North American shops today.

Europe: European practice has moved more aggressively toward IFC across the full project lifecycle, driven partly by the EU's public procurement digitization agenda and partly by the broader adoption of buildingSMART's Open BIM framework among Scandinavian, German, and Dutch contractors and owners. A German or Dutch fabricator receiving a Tekla IFC model is more likely to have the toolchain to consume it directly than a comparable North American shop.

Importantly, DSTV-NC (the German steel construction industry's CNC format) is the European equivalent of the CIS/2 Level 3 fabrication data package. DSTV-NC files are generated from the detailing model independently of whether the input was CIS/2 or IFC. Both formats can serve as the upstream input to a DSTV-NC generation workflow; the format decision at the model exchange level does not determine the CNC output format.

Asia-Pacific: Asia-Pacific practice is heterogeneous, with Japanese and Korean practice historically following AISC-aligned workflows (including CIS/2) for steel-heavy projects, while Australian and Singapore practice increasingly aligns with European Open BIM mandates. Tekla Structures is dominant in Australian steel detailing, and Australian owners specifying IFC4 handover are well-served by Tekla's certified IFC export. The major Asia-Pacific BIM market players — Bentley, Nemetschek, Trimble, Hexagon, Autodesk — all support IFC4.3, which makes IFC the practical lingua franca for cross-border project coordination.

The procurement mandate effect is the strongest forcing function. When an owner's BIM Execution Plan or a government specification mandates IFC as the project data standard, the coordination deliverable format is not a choice. The practical question becomes: can the structural team deliver IFC at the required fidelity while maintaining their own analysis workflow in whatever tools they prefer? The answer is yes, and the mechanism is the two-track workflow: CIS/2 internally for analysis, IFC for external deliverables. This is not a compromise — it is the technically correct architecture for the two different use cases.

Performance and file size: a practical consideration

IFC physical model files for detailed steel models are large. A 500-element steel frame with full bolt and weld detail in IFC will be 10–50x larger than the equivalent CIS/2 Level 1 analytical model, primarily because the IFC file carries explicit 3D solid geometry (extrusion bodies, swept profiles) for every element, while the CIS/2 Level 1 file carries only the wireframe and section designator strings.

For analysis workflow where the file moves between engineering workstations, CIS/2's compactness is an operational advantage. A 2 MB CIS/2 Level 1 file for a complex hospital structure is not unusual; the equivalent IFC physical model file from Tekla might be 150–400 MB. The IFC file's size is justified by its content — it includes everything the coordination model needs. But for the analysis-only exchange between engineers, that content is dead weight that slows import and adds no analytical value.

SDS/2's CIS/2 Level 3 files are larger than Level 1 files because they include fabrication data, but still substantially smaller than IFC full-detail exports because the fabrication data is represented in CIS/2's compact STEP encoding rather than as 3D solid geometry.

Anti-patterns

Anti-pattern 1: "Just use IFC for everything, it's the open standard"

This is the most common error made by project managers and BIM coordinators who have internalized the "open BIM" message without understanding what IFC's physical model actually carries. The failure mode is predictable: the structural engineer exports an IFC file from Tekla, the analysis team imports it into RISA, and immediately notices that none of the load cases are there. The releases are gone. The support conditions are default fixed because the importer reconstructed them from the geometry. The team spends two days manually reconstructing the analytical model from the IFC physical model.

IFC is the right choice for coordination. For analysis model exchange, it is not. Every analysis tool in common use (RISA, RAM, GT STRUDL, ETABS via its IFC analytical model support, STAAD.Pro) has a tested CIS/2 pathway that preserves the analytical model faithfully. Using IFC for analysis model exchange without explicitly verifying that both the exporting and importing tools support IFC structural analysis view (not just physical model view) is asking for silent data loss at the worst possible moment.

Anti-pattern 2: "Always use CIS/2, it's the steel standard"

The equal and opposite error. A team insisting on CIS/2 for all steel data exchange faces three failure modes:

First, the coordination model cannot be built from CIS/2 alone. When the structural steel team delivers a CIS/2 file to the BIM coordinator, the coordinator must either translate it to IFC (using SteelVis or an equivalent tool) or re-model the steel from scratch in the coordination environment. The SteelVis translation is one-way (CIS/2 to IFC only, no reverse path) and is known to drop connection geometry and non-standard sections.

Second, European and Australian project requirements often mandate IFC for all discipline handovers. A team committed to CIS/2-only delivery cannot satisfy these requirements without adding a translation step.

Third, fabricators in IFC-first ecosystems will receive a CIS/2 file and have to open it in SteelVis or a compatible viewer, then manually extract the data they need. This is not a workflow; it is a process breakdown.

Anti-pattern 3: Lossy double conversion

The most insidious anti-pattern: CIS/2 → IFC (via SteelVis) → back into an analysis tool.

This workflow appears when a project team starts in CIS/2 for analysis, produces an IFC for the federated model, then someone decides to use the IFC file as the "master" and feed updates back through the IFC into the analysis tools. The IFC file produced by SteelVis drops connection geometry, may lose non-standard section shapes, and omits data that had no IFC equivalent at translation time. Using that IFC file as the update source means the analysis model is being rebuilt from a degraded representation of itself.

The correct workflow is to maintain the CIS/2 analysis model as the authoritative source for analysis exchanges and produce the IFC independently from the detailing model (Tekla or SDS/2), not by translating the CIS/2 file.

Anti-pattern 4: Version mismatch

IFC version mismatches are a common source of silent data loss. A Tekla IFC 4.3 export received by a Navisworks version that only processes IFC 4 (IFC 4.0) may silently drop IFC 4.3-specific entities and properties, producing a model that visually looks complete but is missing semantic data.

CIS/2 version mismatches are less common because there have only been two releases (CIS/1 and CIS/2) and CIS/2 has been stable since 2000, but different tools may implement different subsets of the CIS/2 schema. A CIS/2 file exported from SDS/2 at Level 3 (including fabrication-specific entities) imported into RISA at Level 1 will silently ignore all Level 3 entities — which is the expected behavior, but can surprise teams who expect full-fidelity transfer.

The mitigation is simple: specify the target schema version explicitly in the project BIM Execution Plan, validate all exchange files against the specification before first delivery, and use NIST's SteelVis as the validation baseline for any CIS/2 file.

Case studies

Case study 1: High-rise moment frame — analysis-first, CIS/2 hub

Context: A 38-story mixed-use tower in a seismic zone. Structural system: steel moment frame with buckling-restrained braced frames at the core. The structural engineering firm used RISA-3D for global analysis and RAM Connection for connection design. The detailer was a specialist steel detailing subcontractor using SDS/2. The BIM coordination model was managed by the general contractor using Navisworks.

Format decisions and outcomes:

The analysis team established CIS/2 as the exchange format between RISA and RAM from the project outset. Every design iteration — and there were eleven over the 14-month design phase — exchanged the analytical model via CIS/2 Level 1. Load cases traveled intact: 18 seismic load combinations per ASCE 7-22, 12 wind load cases, 4 gravity load cases. Member releases for the moment connections and the pin connections at brace ends traveled intact. The RAM Connection team received an analytical model that matched exactly what RISA had computed.

The SDS/2 detailer received CIS/2 Level 2 files from the structural engineer and CIS/2 Level 3 files returned to the fabricator. The Level 3 files included DSTV CNC data for the column web stiffeners and moment end-plates.

For coordination, Tekla Structures was used to produce the IFC model from the SDS/2 detailing data. The IFC model was delivered to the general contractor's BIM coordinator and federated with the MEP model. Clash detection identified 23 hard clashes between steel beams and MEP main duct runs; all were resolved before steel was fabricated.

The key insight: the CIS/2 hub operated entirely within the analysis and fabrication domain. The IFC model was produced from the fabrication-ready Tekla model, not from the CIS/2 analysis model. There was no CIS/2-to-IFC translation step in the critical path.

Lesson: CIS/2 as the analysis-phase hub requires no IFC translation until the model reaches the detailing stage. The IFC should originate from the detail model, not from the analysis model.

Case study 2: Airport terminal expansion — IFC mandate, coordinated from day one

Context: A major international airport terminal expansion. The project operated under a public sector BIM mandate requiring IFC 4.3 for all discipline model deliverables at each project milestone. The structural engineer used ETABS for analysis and Tekla Structures for the fabrication-ready steel model. The architect used Revit. The MEP contractor used Revit MEP.

Format decisions and outcomes:

The structural engineer faced the challenge of satisfying the IFC mandate while maintaining analytical model integrity. The solution was a two-track workflow:

Track A (analysis): ETABS used its native analytical model. For exchanges with the structural engineer's own internal team and with peer reviewers, CIS/2 Level 1 was used because ETABS's CIS/2 support is mature and captures load combinations and member releases faithfully.

Track B (coordination): Tekla Structures was updated from the ETABS analytical model via a direct ETABS-Tekla link (not via CIS/2). Tekla then produced IFC 4.3 certified exports at each milestone. The buildingSMART-certified property sets included material grades, cross-section names, fabrication status, and zone information. The IFC files were delivered to the BIM coordinator and validated in Solibri before submission.

The pain point emerged at the first peer review. The peer reviewer's structural analysis team used RISA-3D and expected to receive a CIS/2 Level 1 file for independent verification. The structural engineer had to add a CIS/2 export step to their ETABS workflow specifically for the peer review deliverable — a step that had not been planned for.

Lesson: Even on IFC-mandated projects, CIS/2 capability must be retained for peer review and structural analysis exchanges. The IFC mandate governs the coordination deliverable; it does not govern every structural exchange in the project.

Case study 2a: Lessons on IFC property set configuration in Tekla

This is a shorter technical note rather than a full case study, but it captures a failure mode that repeats across IFC-mandated projects and deserves its own entry.

A structural consultant on a large commercial development delivered IFC 4.3 files from Tekla Structures 2024 at the schematic design milestone. The owner's BIM manager received the files and immediately noticed that material grade was showing as "undefined" in the Solibri quality check tool. The consultant had exported with the default Tekla IFC export settings, which do not automatically populate the buildingSMART Pset_StructuralProfileItem property set. The YieldStress and YoungModulus values were absent.

The fix required the consultant to configure the Pset definitions in Tekla's property set definition XML file and re-export. Tekla's documentation for Pset creation is detailed and the mechanism works; the issue was that the default export settings target coordination geometry rather than structural property completeness.

The lesson: IFC compliance (the file is a valid IFC 4.3 file that passes schema validation) is not the same as IFC fitness for purpose (the file contains the property data the receiver actually needs). Before the first delivery on any IFC-mandated project, the structural engineer and the BIM coordinator should agree on a specific property set requirements list and validate the first export against that list — not against generic IFC schema validity. Solibri's Information Checkout rules or a custom buildingSMART IDS (Information Delivery Specification) file are the current best practice for this validation step.

Case study 3: Industrial steel building — fabricator-led workflow

Context: A large pre-engineered steel building for an industrial client. The structural steel fabricator-erector was the prime contractor for the structural scope. The fabricator used SDS/2 for detailing and fabrication management. The owner's structural consultant checked the design in RISA-3D and required connection design from RAM Connection.

Format decisions and outcomes:

In this fabricator-led workflow, CIS/2 was the unambiguous primary format. The SDS/2 Level 3 CIS/2 file was the authoritative model: piecemark data, CNC programs, gathering information, erection sequence, and analysis model all in one file or a tightly linked set of files. RISA imported the Level 1 data for independent design verification. RAM Connection imported the structural model for connection checking.

No IFC coordination model was required by the owner's contract documents. The project delivered on schedule with zero fabrication errors attributable to data exchange. The fabricator's opinion of IFC for this project type was direct: for shop management, CNC production, and erection planning, IFC does not yet offer anything that CIS/2 Level 3 does not do better in the North American fabrication context.

Lesson: Fabricator-led structural scopes with no multi-discipline BIM coordination requirement are a clear CIS/2 domain. The format's supply-chain coverage — from analysis through fabrication — is unmatched for this project type.

Case study 4: Steel bridge — IFC 4.3 infrastructure domain

A short-span pedestrian bridge — HSS tube truss, weathering steel, 38-meter span — was designed by a structural firm using RISA-3D for analysis and Tekla Structures for the detailed model. The owner was a municipal authority whose asset management system accepted IFC 4.3 as the as-built handover format.

The project highlighted both the maturity and the limits of IFC 4.3's infrastructure extensions. The IfcAlignment entities introduced in IFC 4.3 correctly described the bridge's horizontal and vertical alignment. The truss members exported as IfcMember with HSS section profiles expressed via IfcRectangleHollowProfileDef — parametric and geometrically complete. The weathering steel grade (ASTM A588) was carried via IfcMaterial and Pset_StructuralProfileItem.

The limit emerged at the anchor bolt detail. The bridge's concrete abutment bearing plates used a cluster of ASTM F1554 anchor bolts. IfcMechanicalFastener with PredefinedType = ANCHORBOLT correctly identified these elements, and Pset_MechanicalFastenerAnchorBolt carried the embedment depth and thread length. But the specific F1554 Grade 36 designation — a designation the owner's structural inspector needed to verify against the approved submittals — had to be placed in a custom property rather than a standardized Pset attribute, because Pset_MechanicalFastenerAnchorBolt does not include a material grade field in the IFC 4.3.2 schema.

Custom properties are not an IFC failure — they are a designed extension mechanism. But they require the receiving tool and the receiving person to know to look for a custom property named "AnchorBoltGrade" (or whatever name the exporting engineer chose) rather than a standard Pset attribute. Documentation of custom property names in the project's BIM Execution Plan is non-negotiable when custom properties carry structurally significant data.

Lesson: IFC 4.3 handles bridge steel geometry and material grades reliably. For fastener-specific attributes beyond the basics, custom properties are available but require explicit documentation in the BIM Execution Plan so receiving parties know where to look.

The two-track workflow: a practical implementation pattern

The most robust approach for projects that require both analysis model exchange and coordination model delivery is the explicit two-track workflow. It does not require choosing between CIS/2 and IFC; it assigns each format to the context where it performs best and keeps the origins clean.

Track A — Analysis and fabrication (CIS/2 hub):

1. Structural engineer completes analytical model in RISA-3D, RAM, GT STRUDL, or ETABS
2. CIS/2 Level 1 export to analysis exchange partners (peer review, owner's independent checker)
3. CIS/2 Level 1 import into connection design software (RAM Connection, IDEA StatiCa)
4. Updated CIS/2 Level 1 or Level 2 file passed to detailer (SDS/2, Tekla via S3D plugin)
5. CIS/2 Level 3 from detailer to fabricator (including DSTV CNC data, piecemark data, gathering)

Track B — Coordination and handover (IFC hub):

1. Detailer (Tekla, SDS/2) produces IFC export from the detailing model — NOT from the CIS/2 file
2. IFC file validated in Solibri or equivalent against agreed property set requirements
3. IFC delivered to BIM coordinator for federation with architectural and MEP models
4. Clash detection and spatial coordination run against the federated model
5. Owner receives IFC at project milestones and at handover
6. Asset management system ingests IFC for facility management lifecycle

The rule that makes this work: the IFC file always originates from the detailing model, never from a translation of the CIS/2 analytical model. The detailing model is the point where analysis-phase decisions (member sizes, grades) and fabrication-phase decisions (connection geometry, hole patterns) have been reconciled. It is the only source in the workflow that has all the information both tracks need expressed in a consistent geometric and semantic model.

Limits and caveats

This post reflects the state of the toolchain as of mid-2026. The landscape is moving, and several shifts are underway that may change the calculus within the next few years.

IFC fabrication-readiness is improving. SDS/2 2026's announcement of "enriched IFC exports with welding data including robotic layout nodes" is a meaningful step toward IFC coverage of fabrication-level data. If IFC becomes a reliable carrier of DSTV-equivalent CNC data, the argument for CIS/2 in North American fabrication workflows weakens significantly. Watch this space.

CIS/2 is not being actively developed. AISC shifted its formal interoperability focus to IFC. NIST's SteelVis received its last update in 2022 (version 8.92). The CIS/2 schema has not been revised since the early 2000s. For the foreseeable future, CIS/2 will remain useful precisely because the installed toolchain is mature and stable — but "stable" in this context also means "not keeping up with new structural systems, new section shapes, and new analysis methods."

The IFC structural analysis view needs more implementation support. The entities exist in the schema to carry full analytical models — load cases, releases, results — through IFC. The obstacle is that few tools implement both the structural analysis view export and import consistently. Until RISA, RAM, GT STRUDL, and ETABS can reliably exchange analysis-model data through IFC structural analysis view, CIS/2 remains the practical analysis exchange format regardless of what the standards landscape says.

Regional procurement mandates are the strongest forcing function. If your projects are in jurisdictions where IFC is mandated in public procurement contracts (UK, Netherlands, Norway, Singapore, and growing lists elsewhere), the format decision is already made for the coordination deliverable. The question is only how to fulfill the mandate without breaking your analysis workflow. The answer — CIS/2 for analysis, IFC for coordination, IFC originating from the detail model not from a CIS/2 translation — is consistent across all mandated-IFC jurisdictions.

Python tooling note: The code sample below is a starting point. Both CIS/2 and IFC physical files are text-based STEP Part 21 format and can be parsed with the same tokenizer. The semantic interpretation — what constitutes a "member" vs. a "node" vs. a "load" — requires schema-specific logic.

"""
Parse CIS/2 and IFC STEP Part 21 files.
Both formats use ISO 10303-21 physical file encoding.
Requires: ifcopenshell (pip install ifcopenshell) for IFC;
          manual parsing for CIS/2 (no standard Python library).
"""
 
import re
from dataclasses import dataclass, field
from typing import Optional
from pathlib import Path
 
 
# =============================================================
# Shared: STEP Part 21 tokenizer (works for both CIS/2 and IFC)
# =============================================================
 
STEP_ENTITY_RE = re.compile(
    r"#(\d+)\s*=\s*([A-Z_0-9]+)\s*\(([^;]*)\)\s*;",
    re.DOTALL
)
 
def parse_step_instances(filepath: str) -> dict:
    """
    Return a flat dict of {instance_id: (entity_name, raw_args_string)}
    from any STEP Part 21 file (.stp or .ifc).
    """
    text = Path(filepath).read_text(encoding="utf-8", errors="replace")
    data_section = re.search(r"DATA;(.+?)ENDSEC;", text, re.DOTALL)
    if not data_section:
        raise ValueError(f"No DATA section found in {filepath}")
 
    instances = {}
    for m in STEP_ENTITY_RE.finditer(data_section.group(1)):
        inst_id  = int(m.group(1))
        ent_name = m.group(2).upper()
        raw_args = m.group(3).strip()
        instances[inst_id] = (ent_name, raw_args)
    return instances
 
 
# =============================================================
# CIS/2 parser: extract analysis-model members (Level 1)
# =============================================================
 
@dataclass
class Cis2Member:
    member_id: int
    entity_ref: int            # #n reference in the STEP file
    member_type: str           # COLUMN, BEAM, BRACE, etc.
    section_name: str          # e.g. 'W21X68'
    material_grade: str        # e.g. 'A992'
    start_node_id: Optional[int] = None
    end_node_id:   Optional[int] = None
 
def extract_cis2_members(filepath: str) -> list[Cis2Member]:
    """
    Parse a CIS/2 STEP Part 21 file and return structural members.
    This is a simplified extractor; full CIS/2 parsing requires
    implementing the complete EXPRESS schema in Python.
    """
    instances = parse_step_instances(filepath)
    members = []
 
    for inst_id, (ent_name, raw_args) in instances.items():
        # CIS/2 member entity names vary by software vendor;
        # common patterns include CS_MEMBER, STRUCTURAL_MEMBER,
        # and ANALYTICAL_MODEL_ELEMENT.
        if "MEMBER" in ent_name and "SECTION" not in ent_name:
            # Naive extraction: split comma-separated args
            args = [a.strip().strip("'") for a in raw_args.split(",")]
            try:
                member_id   = int(args[0]) if args[0].isdigit() else inst_id
                member_type = args[1].strip(".") if len(args) > 1 else "UNKNOWN"
                section_ref = args[2] if len(args) > 2 else ""
                grade_ref   = args[3] if len(args) > 3 else ""
 
                # Resolve section name from referenced entity
                section_name = "UNKNOWN"
                if section_ref.startswith("#"):
                    sec_id = int(section_ref[1:])
                    if sec_id in instances:
                        sec_args = instances[sec_id][1]
                        sec_parts = [a.strip().strip("'") for a in sec_args.split(",")]
                        section_name = sec_parts[1] if len(sec_parts) > 1 else "UNKNOWN"
 
                members.append(Cis2Member(
                    member_id    = member_id,
                    entity_ref   = inst_id,
                    member_type  = member_type,
                    section_name = section_name,
                    material_grade = grade_ref.lstrip("#"),
                ))
            except (IndexError, ValueError):
                continue  # Skip malformed entities
 
    return members
 
 
# =============================================================
# IFC parser: extract structural steel members using ifcopenshell
# =============================================================
 
def extract_ifc_steel_members(filepath: str) -> list[dict]:
    """
    Parse an IFC file and return steel structural members.
    Uses ifcopenshell for schema-aware parsing.
 
    pip install ifcopenshell
    """
    try:
        import ifcopenshell
        import ifcopenshell.util.element as ifc_util
    except ImportError:
        raise ImportError(
            "ifcopenshell is required for IFC parsing. "
            "Install with: pip install ifcopenshell"
        )
 
    model = ifcopenshell.open(filepath)
    results = []
 
    # Target entity types for structural steel
    steel_entity_types = [
        "IfcBeam",
        "IfcColumn",
        "IfcMember",       # braces, inclined members, generic structural
        "IfcPlate",        # gussets, base plates, stiffeners
    ]
 
    for entity_type in steel_entity_types:
        for element in model.by_type(entity_type):
            # Get material information
            material_name = "Unknown"
            mat_assoc = ifc_util.get_material(element)
            if mat_assoc:
                if hasattr(mat_assoc, "Name"):
                    material_name = mat_assoc.Name or "Unknown"
                elif hasattr(mat_assoc, "ForProfileSet"):
                    # IfcMaterialProfileSetUsage -> IfcMaterialProfileSet
                    profile_set = mat_assoc.ForProfileSet
                    if profile_set and profile_set.MaterialProfiles:
                        first_profile = profile_set.MaterialProfiles[0]
                        material_name = (
                            first_profile.Material.Name
                            if first_profile.Material else "Unknown"
                        )
 
            # Get profile/section name
            profile_name = "Unknown"
            if mat_assoc and hasattr(mat_assoc, "ForProfileSet"):
                pset = mat_assoc.ForProfileSet
                if pset and pset.MaterialProfiles:
                    profile = pset.MaterialProfiles[0].Profile
                    if profile:
                        profile_name = profile.ProfileName or profile.is_a()
 
            # Get structural properties from Pset_StructuralProfileItem
            yield_stress = None
            psets = ifc_util.get_psets(element)
            structural_pset = psets.get("Pset_StructuralProfileItem", {})
            yield_stress = structural_pset.get("YieldStress")
 
            results.append({
                "global_id":    element.GlobalId,
                "entity_type":  element.is_a(),
                "name":         element.Name,
                "tag":          element.Tag,
                "predefined_type": getattr(element, "PredefinedType", None),
                "material":     material_name,
                "profile":      profile_name,
                "yield_stress_pa": yield_stress,
            })
 
    return results
 
 
# =============================================================
# Usage example
# =============================================================
 
if __name__ == "__main__":
    import json
 
    # CIS/2 example
    cis2_file = "frame_analysis.stp"
    try:
        cis2_members = extract_cis2_members(cis2_file)
        print(f"\nCIS/2: Found {len(cis2_members)} structural members")
        for m in cis2_members[:5]:  # print first 5
            print(f"  #{m.entity_ref}: {m.member_type} {m.section_name} ({m.material_grade})")
    except FileNotFoundError:
        print(f"CIS/2 file not found: {cis2_file}")
 
    # IFC example
    ifc_file = "structural_steel.ifc"
    try:
        ifc_members = extract_ifc_steel_members(ifc_file)
        print(f"\nIFC: Found {len(ifc_members)} structural steel elements")
        for m in ifc_members[:5]:  # print first 5
            print(
                f"  {m['entity_type']} '{m['name']}': "
                f"profile={m['profile']}, material={m['material']}"
            )
    except FileNotFoundError:
        print(f"IFC file not found: {ifc_file}")

Decision framework

Step 1: Identify the receiver

Before opening any export dialog, identify every system and person who will consume the file. Write them down. Analysis software? Coordination viewer? Owner's facility management system? Fabricator's shop management software?

Step 2: Map receiver capabilities

For each receiver: does it consume CIS/2 natively? At what level (L1, L2, L3)? Does it consume IFC? Which version (IFC 2x3, IFC4, IFC4.3)? Does it support the IFC structural analysis view or only the physical model view?

Step 3: Apply the primary rule

If the receiver is analysis software (RISA, RAM, GT STRUDL, STAAD.Pro, ETABS via CIS/2): use CIS/2 Level 1.

If the receiver is a coordination platform (Navisworks, Solibri, BIMcollab, Revit link, owner review platform): use IFC.

If the receiver is a fabrication management system in North America (SDS/2, Tekla PowerFab, FabSuite): use CIS/2 Level 3 or verify IFC fabrication support before committing.

If the receiver is a fabrication management system in Europe/Australia/Singapore: verify IFC support; IFC is increasingly viable.

Step 4: Locate the format origin

The format must originate from the software that has the data the receiver needs. CIS/2 for analysis must come from the analysis software, not from a detailing model. IFC for coordination must come from the detailing model (Tekla, Advance Steel, SDS/2), not from a CIS/2 translation.

Step 5: Validate before sending

Validate CIS/2 files in NIST SteelVis before delivery. Validate IFC files in Solibri or a buildingSMART-certified tool before delivery. A file that looks correct in the exporting software may have silent defects that only appear when a different tool tries to consume it.

Step 6: Document the exchange protocol in the BIM Execution Plan

The BIM Execution Plan should specify, for each exchange: format, version, model level, origin software, receiving software, validation tool, and delivery cadence. Ambiguity in exchange protocols is the proximate cause of most format disputes on projects.

Sources and further reading

The following sources were consulted and verified in the preparation of this article. All URLs were checked for HTTP 200 status at the time of authorship (June 2026).

Primary sources:

1. NIST SteelVis (CIS/2 Viewer) — The reference CIS/2 validation tool and the authoritative NIST stewardship resource for CIS/2. Version 8.92, 2022. nist.gov/services-resources/software/steelvis-aka-cis2-viewer

2. Lipman, R.R. (2009). "Details of the Mapping Between the CIS/2 and IFC Product Data Models for Structural Steel." Journal of Information Technology in Construction, Volume 14. NIST-published research establishing the definitive CIS/2-to-IFC mapping and identifying IFC schema deficiencies for structural steel. nist.gov/publications/details-mapping-between-cis2-and-ifc-product-data-models-structural-steel

3. IFC 4.3.2 Documentation — IfcMember — The authoritative buildingSMART schema reference for the primary structural steel member entity. ifc43-docs.standards.buildingsmart.org/.../IfcMember.htm

4. IFC 4.3.2 Documentation — IfcMechanicalFastener — Schema reference for bolt and fastener representation. ifc43-docs.standards.buildingsmart.org/.../IfcMechanicalFastener.htm

5. IFC 4.3.2 Documentation — IfcDiscreteAccessory — Schema reference for connection hardware and discrete accessories. ifc43-docs.standards.buildingsmart.org/.../IfcDiscreteAccessory.htm

6. buildingSMART International — IFC 4.3 Approved as Final Standard (January 2024) — Official announcement of ISO 16739-1:2024 approval. buildingsmart.org/ifc-4-3-approved-as-a-final-standard

7. SDS/2 Technical Support — CIS/2 Export Documentation — Vendor documentation for SDS/2's CIS/2 Level 1–3 export capabilities including AISC EM11 Phase 2 compliance. techsupport.sds2.com/main/Topics/cis2_ex.htm

8. Tekla User Assistance — IFC Export (2025) — Trimble's authoritative documentation for Tekla Structures IFC export, confirming IFC2X3, IFC4, and IFC4.3 schema support and buildingSMART certification. support.tekla.com/doc/tekla-structures/2025/int_ifc_export

9. Tekla User Assistance — Why some beams are IfcMember not IfcBeam — Technical explanation of Tekla's 20–70 degree slope reclassification behavior. support.tekla.com/article/why-are-some-beams-ifcmember-and-not-as-ifcbeam-in-ifc-export

10. AECbytes — SDS2 2026: Automation and Interoperability in Steel Detailing (2025) — Review of SDS2 2026 features including enriched IFC welding data and BIMPLUS integration. aecbytes.com/sponsored/2025/SDS2-2026.html

Further reading:

• ITcon Vol. 14 (2009) — The full Lipman paper on CIS/2-IFC mapping with complete entity-level correspondence tables: itcon.org/paper/2009/01
• buildingSMART MVD Database — Current Model View Definitions including Coordination View 2.0: technical.buildingsmart.org/standards/ifc/mvd/mvd-database
• RAM Structural System — CIS/2 Export Options — Bentley documentation on RAM CIS/2 payload: docs.bentley.com/...CIS/2 Export Options
• GTSTRUDL Features — GT STRUDL's bidirectional CIS/2 capabilities: gtstrudl.eu/index.php/strudl-features