Managing bridges in dTIMS begins with the management of data that describes the bridge at different levels. The level of data granularity will define the database structure. Regional guidelines from national standards will specify the data you have to collect for a bridge, which can be at the object level (main bridge), component level (superstructure, substructure, deck), or element level (girders, piers, bearings, etc.). The database structure you implement in dTIMS must fit into these requirements and specifications.
Database Structure
How do you structure a bridge database? You start by defining a master object which can consist of more than one object. You will need to decide if your master object should be split into two individual objects. Generally, a master object does not only consist of different construction types, it can also consist of different object types if you want to have them within one analysis.
Start by defining the key use of dTIMS. Should it store all available data, or just consume the data available for analysis? What outputs are required? What level of granularity do you want to achieve?
Generally, you will have the following data types:
- System Data - which gives us the basic information about the object, such as ID, name, location, and type
- Inventory Data - for the object or each component
- Condition Data - also different opportunities for object-level and component-level
- Traffic - AADT for example
- Treatment Data - can be historical treatments that have been applied on your object, but that can also be a forecast of already planned treatments in the future.
Configuration
How can you set this up in dTIMS? We recommend you use available standards and regulations for the definition of the structure. This ensures that the output and reports are generated in the format needed. dTIMS is flexible in defining tables, attributes, and their relations as needed, and will then store the data as it becomes available.
Example 1 - Bridge Database Design
Let's take a look at example 1 to the right. At the top, there is the System Data (base) header where we are showing one dataset for each bridge, which can be linked to a road network or created independently. When looking at this base table, you can see that we have much more data than just the one superstructure. Within dTIMS, you can include multiple elements (lines in the table) on one bridge, allowing you to store more relevant data directly related to the superstructure.
On the condition side, we might have data on the object level, but we will also have it on the different components from different points in time, generating the opportunity for historical data to be stored. All the information needed will end up in an analysis table.
To summarize, your database configuration will include tables for:
- Object data
- All Components
- Condition data
- Traffic data
- Treatments
Conclusion
Requirements and specifications have become more complex. Not because the nature of a bridge is slightly more complex compared to pavement, but because business processes have become more complex. It is necessary to have a product available that supports complex business processes.
The dTIMS hierarchical database represents a solution to multi-level data organization for bridge management.
Are you interested in a client-based bridge configuration example? Fill out the form below for access to our webinar recording to get the full story!
Looking for a bridge demo or to speak with a specialist? Fill out the form below with your contact information and questions, and a member of our team will get back to you!