Revolutionize Your Traditional Workflow

Using MDX, ConSpan, and RCPier for preliminary bridge design, and CsiBridge, Larsa 4D, Lusas, and Midas Civil for final bridge design? If you're in search of a more efficient alternative, OpenBrIM Platform could be the solution you've been looking for. Dive into this article to gain a comprehensive understanding.

When we delve into the patterns of user choices, it's crucial to understand that we cannot and should not fault users for gravitating towards one software over another for a specific task, even if the software appears old/outdated or if they rely on a myriad of software packages for their tasks.

In a recent LinkedIn post, Steve Tissier, a Bridge/Digital Engineer at AtkinsRéalis and a user of the OpenBrIM Platform, classifies the current software they use for bridge design prior to the OpenBrIM Platform as follows:

• Prestressed Concrete Girders: Conspan/Leap Bridge Concrete, PG Super, Mathcad sheets.

• Steel I-Girder or Tub Girders: MDX, Leap Bridge Steel, Midas Civil, CSI Bridge.

• Steel Girder Design & Code Checks (for tasks the above programs don’t address): Excel or Mathcad hand calculations.

• Segmental: LARSA 4D, Midas Civil, etc.

• Substructure: RC-Pier (Leap Bridge Concrete), Excel or Mathcad hand calculations.

• Foundations: FB-Multipier,

As founders and CEOs, we consistently observe trends transforming other industries, aiming to apply similar reasoning to our products and businesses. Reflect on the moment when Steve Jobs unveiled the iPhone in that iconic keynote. The graph below highlights how the iPhone's intuitive and advanced technology swiftly surpassed the hard-to-use and not-so-smart phones of the time, ushering in a new era for the mobile industry.

Open

In 2005, there were compelling reasons to choose a BlackBerry, just as there were for choosing simpler Nokia models. Drawing a parallel, we believe that today's engineering software landscape mirrors the mobile scene of 2005. There isn't a clear frontrunner in each category; some programs are user-friendly but lack in advanced computation capabilities, while others offer power at the cost of user experience.

Choosing the Software for Steel Superstructure Design: Insights from User Feedback

While each software vendor might contest the below observations, we've based these statements on feedback from our users, striving for as much neutrality as possible.

Statement 1: Even though MDX's technology might seem outdated, it's still in use for three pivotal reasons: efficiency, trustworthiness, and user familiarity.

Open

Statement 2: If you're seeking greater control over your finite element model and are primarily focused on analysis rather than design—despite these tools offering design capabilities—you'd likely gravitate towards Midas Civil, CSI Bridge, or LARSA 4D. Typically, the choice among these three hinges on the software familiarity of the company or the expertise of the lead engineer.

Statement 3: On the other hand, Leap Bridge Steel is a newer tool compared to the other four alternatives and can be grouped in the same category as MDX from a design spec check perspective. While the software looks and feels superior to MDX and is more efficient than Midas Civil, CSI Bridge, and LARSA 4D, its trustworthiness lags behind that of the other four.

The statement above prompts us to categorize the selection process into three key factors: efficiency, trust in the software, and familiarity with the software.

Efficiency/Speed: Drawing from the insights shared by our users above, a central factor that guides software selection is its efficiency in addressing specific tasks. Time is an invaluable resource, and users frequently ask the question: 'How quickly can I achieve my desired goal using this tool? Speed directly correlates with an increased number of design iterations, facilitating engineers in effortlessly meeting project deadlines.

In the corporate sphere, there may be arguments, particularly within the bridge engineering industry, regarding the billing of engineers' time to agencies. However, we firmly believe that this business model is on the cusp of transformation, a change that is already underway, thanks to the influence of design-build projects in the industry today.

Trust: Trust in bridge design or engineering software is an important factor because the results of FEA analyses and spec checks influence design decisions, safety assessments, and the overall success of engineering projects. No engineer wants to take a risk with software that is not established or has a bad reputation in the industry for that specific task. So, when software loses its reputation or trust for a specific task, it is typically replaced with alternative options shortly.

Software Familiarity: When considering engineering software selection for projects, expertise in using a specific software is often a crucial factor. If you have been using a software package for over 15 years, it can be challenging to switch to a newer technology, even if it offers superior features. Typically, experienced engineers who are well-versed in a particular software have the authority to choose, while younger engineers must adapt to their preferences.

Preliminary Design: From our discussion with our users, in the context of preliminary design, efficiency and speed emerges as the pivotal factor influencing the software selection decision-making process.
Final Design: However, when it comes to the final design, the engineers' unwavering commitment to safety elevates trust as the primary factor.

Considering these factors, MDX typically stands out as the preferred software choice for preliminary design, while CSI/MIDAS Civil/LARSA 4D/Lusas takes the lead for final design, primarily due to its robust analysis capabilities. However, engineers' lack of trust in their design and specification check capabilities often leads them to extract results from the software and input the results into in-house Mathcad or Excel sheets for specification checks.

Engineers also mention that to address trust issues, it is imperative to collect and compare finite element analysis results from at least one reliable FEA software, such as LARSA 4D, CSI Bridge, Midas Civil, or Lusas. Additionally, conducting specification checks in at least two different locations, which may involve the use of MDX, LEAP, or Mathcad, becomes crucial in guaranteeing the accuracy of the design process.

In fact, this verification process, along with the utilization of diverse software packages for structural design checks, presents a promising opportunity for emerging software platforms like OpenBrIM Platform. While certain tasks, like generating drawings, can be efficiently handled within a single software where one software dominates all project work, it becomes evident that conducting finite element analysis and design tasks necessitates the use of multiple software tools, as mentioned above. By comparing results from these different sources, engineers can bolster their confidence in both the design and the software itself. That's why every software platform can be a winner for the analysis and design as long as they provide value to engineers.

#OneSoftwareToRuleThemAll

In the same LinkedIn post mentioned above, Steve Tissier highlighted the OpenBrIM Platform using the hashtag #OneSoftwareToRuleThemAll. Now, let's delve into the fascinating journey of crafting the OpenBrIM Platform to excel in every aspect, making it a champion across the board.

Let's start by revisiting the fundamentals: How can we create a user interface that is not only user-friendly but also adored by every engineer in the field?

To find the answer, let's examine their preferences, and the solution is rather straightforward. Engineers have a deep affection for Excel; they find comfort in working with Excel spreadsheets and with parameters. Hence, it's clear that gathering inputs within a spreadsheet is the way to go. This method reduces the necessity for extensive on-screen drawing, harmonizing with user preferences and enhancing the overall intuitiveness of the interface.

Now, it's time to consider software like CSI Bridge, Midas, and LARSA 4D – all of which offer features and user interfaces comparable to spreadsheets. How does this similarity set your software apart as a more straightforward option? Now, let's shift our attention to the left side of the screenshot, where you'll notice the bridge components, rather than nodes, beams, and shells. To simplify this process, we're not gathering FEM data; instead, we're solely collecting bridge parameters, akin to the approach taken by MDX or LEAP Steel.

Now, let's address the next question that may have crossed your mind. If we're only collecting bridge parameters, OpenBrIM may seem similar to MDX and LEAP, which may not fully meet your complex analysis and customization needs for finite element analysis. To address this challenge, we've introduced an FEA tab that offers a comprehensive view of the FEM output for each parametric bridge component, including nodes, beams, shell elements, and construction stages. This design closely mirrors the user interface of FEA software like CSI Bridge, Midas, and LARSA 4D. Additionally, we've implemented an override feature that empowers you to modify FEM generated by library components, catering to your specific requirements.

While software tools like Midas Civil, CSI Bridge, LARSA 4D, Lusas, Leap Steel, and MDX offer a range of parameters/wizards for bridge creation, we often find ourselves returning to the fundamental building blocks: nodes, beams, and shells, which we then customize. Why do we do this? Because at its core, engineering is about conquering challenges, venturing into unexplored territories, and crafting solutions that precisely align with the distinctive demands of every project site and bridge project.

While we have introduced enticing override features, as previously explained, to tackle this issue, it's evident that our main objective is to promote the concept of parametric bridge components and discourage data overrides.

How can we effectively achieve this and ensure that OpenBrIM's parametric bridge components are genuinely beneficial for engineers working on real projects?

While we have introduced enticing override features, as previously explained, to tackle this issue, it's evident that our main objective is to promote the concept of parametric bridge components and discourage data overrides. How can we effectively achieve this and ensure that OpenBrIM's parametric bridge components are genuinely beneficial for engineers working on real projects?

To delve deeper into this issue, it's crucial to develop a comprehensive understanding of the challenge at hand. What leads other parametric bridge components or wizards to frequently come up short when it comes to meeting the distinct requirements of your project? To illustrate this, let's draw a parallel with the phone industry's experience in 2007, as Steve Jobs highlighted the limitations of phones equipped with static keyboards. They were fixed in place, meaning that if you had a new idea or needed to develop software with different controls, you had to patiently await the release of an entirely new phone - a process fraught with static and sluggishness. In our context, when your project requires additional parameters for a pier component, traditional software vendors must go through the lengthy process of developing a new feature within their wizard, releasing new software, installing it on your IT infrastructure, and only then can you make use of it. This unrealistic cycle can delay progress by an entire year, leaving you without the means to apply the new parametric bridge wizard to your project's unique requirements.

In order to overcome this challenge, we embarked on a journey to transform how we distribute our software and develop parametric bridge components. Traditional desktop-based solutions proved inadequate, primarily due to the involvement of IT, a process that could take several weeks, and their lengthy software release cycle, which could consume an entire year. Recognizing that the need for an entirely new software package when updating parametric bridge components is similar to expecting every Instagram user who wants to post a selfie to submit a request to Meta Inc. and wait for a new Instagram platform release might seem far-fetched, but it's the exact situation we've encountered in our industry.

Parametric Bridge Engineering On Cloud: When we distribute these customized groundbreaking parametric bridge components, our goal is to effortlessly deliver them to users' computers within seconds. The answer to this challenge is found in the world of the web. As a result, OpenBrIM functions directly within web browsers, allowing users to seamlessly incorporate new parametric bridge components in a matter of seconds. Likewise, all OpenBrIM library objects are open source and can be modified directly within anyone's web browser. We bring parametric definitions to your browser, providing transparency and openness in all these relationships.

The approach mentioned above turned out to be inadequate for our enterprise clients, mainly because the development of parametric bridge components came with a learning curve that didn't fit their workload. In our commitment to ensure their business success, we recognized the necessity to overhaul our support and communication methods, especially for customizing objects. Consequently, we adopted Slack as our primary communication tool, allowing us to understand their project objectives better. This enabled us to develop the necessary bridge components and make modifications based on their specific requests. Today, for every enterprise client, we assign a dedicated project manager to comprehensively grasp their requirements. We swiftly proceed to update the library objects based on their specific requests, often completing these enhancements within a matter of days. Subsequently, all they need to do is simply click the "Check OpenBrIM Library for Updates" button, and they can readily incorporate their new bridge components.

Now, let's explore another problem often seen with old-fashioned wizard-based FEA and design software. Usually, these wizards spit out an FEA model, and users have to fill in lots of tables to see what the final model looks like. Many times, users only notice their mistakes when they see a view of the model, like a 3D model or an FEA model. Typically, they have to keep entering the inputs and checking the final model over and over again. On the other hand In OpenBrIM, whenever a user updates a parameter, all affected views (3D, 2D, or FEM) and reports (such as quantity reports) are promptly updated within seconds. This is how we ensure consistency across all these distinct models. A key factor in achieving efficient and rapid design is the swift and efficient presentation of a holistic view to the user. The video below demonstrates how that process happens in real-time in a web browser.

“We firmly believe that an effective parametric approach is an essential component of any efficient design and iteration process. With our current model, we are confident that we have successfully achieved this goal.”

Now that we've demonstrated our value by effectively assisting users in achieving their tasks with our parametric objects, it's crucial to address the issue of user trust in the software. We believe four key elements play a pivotal role in this process: interoperability, transparency in all computations, providing users with the ability to change parameters and witness their effects to test the software, and an extensive test library for automated testing.

Interoperability: In a standard design project, lead engineers often seek comfort in the software's output. In many instances, they prefer to witness the structure behaving as expected within a workflow they've been accustomed to for the past 15 years. Therefore, we must offer solutions to younger engineers that can demonstrate that they can prove that their way of doing things is the right way. One such solution is ensuring interoperability between the new technology and the software familiar to lead engineers. This way, lead engineers can assess the work of younger engineers using the old methods. With this mindset, OpenBrIM Platform enables seamless exports to software packages like CSI Bridge, LARSA 4D, and Midas Civil.

When it comes to design and specification checks, engineers often rely on their in-house Mathcad or Excel spreadsheets. Our library objects act as digital equivalents to these spreadsheets, allowing users to easily analyze input-output relationships at a component level within OpenBrIM Library. You can see a demonstration of this process in the video below. We've taken the initiative to digitize all AASHTO chapters and design codes, offering users a seamless experience. Once they are satisfied with the algorithm at a component level, their project can call the same library object and utilize it in the computation process.

Another example of transparency can be observed below, where users can simply click on the analysis result spreadsheet and view the real-time load vehicle position that generates the force effect.

Our automated testing and verification system simplifies the process of checking all new library objects and OpenBrIM releases once you have established trust in the software. For more information about our verification system, please visit the following page.

About The Author  ⁄ Cagin Yakar, CEO OpenBrIM Platform

Cagin Yakar is CEO at OpenBrIM Platform in New York. With 15 years of experience leading the development and engineering operations of renowned software products in the USA, particularly in the bridge industry, he brings a wealth of knowledge and expertise to his role. Cagin is a structural engineer and software developer with a Master of Science degree from Columbia University. His valuable knowledge, skill set, and passion drive his career, and he is committed to advancing the industry with his team's innovative approach. Through OpenBrIM, Cagin aims to create the world's first parametric, digital bridge engineering repository on the cloud, revolutionizing the field and transforming the way engineers work.