1.1 Bridge View

The goal of this effort is to automate the exchange of bridge information by defining a standard for representing bridge information in a digital format, which can be rapidly adopted by software vendors with minimal ambiguity. As such, the overall goal is wide-reaching and unbounded. To effectively achieve such a broad goal, part of this effort involved focusing the efforts into a specific data exchange with measurable scope. While there are potentially hundreds of information exchanges over the lifecycle of any particular bridge, spanning design, construction, and maintenance phases, it was concluded that the highest initial value would be on automating what is found in bridge design plans as they go out for bid. This decision was based on (a) such information is most often contracted between different parties rather than used within the same organization such that there is shared incentive in documenting such exchange; (b) examples of this information are already widely published at DOT agencies that can be used to unambiguously define requirements of an information model; (c) providing design results is more likely to be in the business interests of existing bridge software vendors, as opposed to information during the design process which may often substantially vary between vendors along with competitive advantages; and (d) such detailed information is a prerequisite for other exchanges that refer to detailed design information.

In defining this information exchange, it was deemed critical to model specific bridges that are most representative of bridges in the U.S. by quantity, and to model such bridges in full detail, matching the same information provided on existing plan documents. While we cannot assert that the particular information models proposed will accommodate all past and future bridges, we can conclude whether or not specific bridges may be supported and indicate any gaps that would need to be resolved to be supported by proposed information models. As even the simplest bridges consist of thousands of components and measurements, this initial effort is focused on two specific bridges: a 4-span steel girder bridge with curved alignment and constant slope, and a 5-span concrete box girder bridge with curved alignment and parabolic slope.

In defining information models (also referred to as “schemas” herein), it was deemed preferable to attempt to leverage existing information models that may be adapted rather than starting from scratch, as (a) for vendors already supporting existing information models, it may cost significantly less for them to support added functionality compared to new separate models; (b) for existing information models having been applied to a wide range of structures, many unforeseen scenarios have already been addressed; and (c) software tools and developer communities already exist for accelerating development of sample data and additions to such information models.

Industry Foundation Classes (IFC) defines a detailed schema of around 800 data types for representing building components, their relationships, and associated lifecycle information such as tasks, resources, systems, requirements, and project participants. While IFC has historically focused on buildings, all data types are based on function (rather than form or domain), such that most applicable data structures can be directly leveraged for bridges. For example, the IfcBeam data type can be used to define a bridge girder in the same way as in buildings (e.g. girders, floor joists, lintels). IFC supports the entire range of STEP AP214 based geometry (with several exceptions) used to commonly represent manufactured product models, such that it is compatible with virtually all CAD software in every manufacturing and construction domain. Such geometry ranges from tessellation (indexed triangles), boundary representations with arbitrary curved surfaces and openings, swept geometry of arbitrary cross-sections along arbitrary curves, and Constructive Solid Geometry where shapes may be composed based on unions, intersections, subtractions, or clippings. Conceptually, such predefined data types are equivalent to formulas for deriving shapes, but capture more complex shapes than could be represented by arithmetic and trigonometric expressions. IFC 4.1 has introduced several new data types for capturing alignment information for bridges and roadways. IFC 4.2 (anticipated later in 2015) is expected to include extended positioning information directly applicable to bridge geometry.

This specification builds on IFC 4.1 with one additional data type, IfcRelPositions, which is used to indicate positioning of bridge elements relative to an alignment curve. While additional entities could have been added, the goal of this effort is to leverage existing software with minimal impact, and each of the sample bridges was modeled using existing data types. In addition to data types typically found in building models as commonly exported from design software, several extended uses have been documented to support optional information such as parametric information capturing design intent. Inclusion of parametric information is entirely optional, such that bridge designs may be documented with or without such information.