Design model standards update

dsn-mdl-stnd-updat-01.mp4 15:14

Wisconsin DOT started developing design models for our roadway projects as a voluntary deliverable in 2010 when we started using Civil 3D as our roadway design software. In 2014, after a few years of voluntary design model deliveries and pilot project experiences, WisDOT implemented statewide design model delivery requirements that applied to all new design projects with earthwork.  The design model concept we implemented consisted of a group of 3D surface models that represent proposed work terrain.  The 2014 standards required surface models for TOP (which is finished grade of all work), DATUM (which is finished earthwork grade), all roadway base and subbases, and a pavement model. Over our first years of project experiences with design model delivery standards we recognized that there was not strong utilization of some of the surface models on our construction projects, so in 2018 we updated the design model concept by removing Base, Subbases, and Pavement from the list of required surface models, leaving us with today's design model concept that is made up of a Top and a Datum surface model only.  However, continued feedback from project experiences has exposed other elements of our design model implementation that could be improved upon.  We presently have a one-size-fits-all design model concept that requires the same deliverables developed to the same level of detail for all projects with earthwork.  There is no consideration in design model standards for project complexity or other project needs.  In informal conversations with designers and project staff who have experience with design models on WisDOT projects, we've been hearing we could be doing a better job of "right-sizing" the scope of design model development to specific project needs.

What follows is Part 1 of a two-part presentation that describes a proposed concept for restructuring Wisconsin DOT's design model standards that will help us achieve our goal of right-sizing design model delivery efforts.  Part 1 is an overview of the proposed restructuring.  Part 2 will look more closely at the details of how the proposed standard would work, and how it would benefit our Project Delivery environment.

How do we "right-size" the design model effort?

How do we do a better job of right-sizing the 3D design effort to specific project needs?  We've identified 3 measures that will help us achieve that goal.

1. The first is a restructuring of the content and level of detail standards for our design models. The new standards will allow for more variation in content and detail, allowing delivery requirements to be tailored to all types of WisDOT projects and establish a roadway design environment that invests the appropriate amount of 3D design effort for a project's specific needs.  The addition of a model feature examples Library to our design model content requirements will create such a flexible standards framework, I'll explain how and why in this presentation.
2. One problem with a rigid, uniform statewide standard is the unique nature of individual roadway projects.  No two projects are the same.  Projects of the same improvement type can have significantly different needs.  Complex project situations will sometimes benefit from the development of additional detail in design models, while in other project situations that same level of detail development may be overkill.  So, our second goal in developing a Right-Sizing strategy is to allow more project level control over the scope of 3D design deliverables.  The update we are proposing will create a framework for defining 3D design standards, and Regions will work within that framework to tailor the 3D design scope to the specific needs of projects.
3. Our third measure is to develop a standard that communicates and documents 3D design delivery expectations much more clearly than our present day FDM standards.  Today's design model standards set requirements for content and level of detail of our proposed work surface models, but the quality of the communication of those ideas has not been as effective as we need it to be.  Project teams' interpretation and application of our design model standards has not always been consistent.  Restructuring our design model standards provides an opportunity to make improvements in communicating 3D design content and detail expectations, and our proposal is designed to accomplish that.

Design model features example library

Central to our proposed update of design model standards is the Design Model Features Example Library.  The examples in this library will not be full project surface model examples.  Instead, the library will be a collection of 3D models of smaller elements which are often found within a surface model on a Wisconsin DOT roadway project.  These smaller elements represent specific roadway features. Listed on the slide are some of the roadway features we plan to develop examples for in our Model Features Example Library.  We will add more features to the library as the needs become apparent.  Some features will only have a base level of detail example, other features will have multiple example versions with advanced examples containing more detail than the base example.

The FDM's design model standards will reference these model feature examples. In other words, the examples will be part of the FDM standard for defining design model content and detail.  The examples will establish level of detail expectations on a feature by feature basis.  The use of model feature examples will help us achieve our goal of improving communication of design delivery expectations.  It is well understood that one of the benefits of 3D design is that it improves the communication of design concepts, compared to traditional 2D only deliveries.  So, it is ironic that we've been trying to communicate the content of 3D surface models with written text and 2D drawings.  When you think about it that way, it makes sense that a better way to communicate 3D surface model content concepts is with 3D surface models, so we will be bringing our design standards into 3D.

Each Model Feature will have a base level of detail example.  The content and detail of a feature's base example will be the statewide design model delivery requirement, it will define the minimum amount of detail a surface model must contain, on a feature by feature basis.  Some model features will have advanced levels of detail representations in the library, in addition to the base level example.  Advanced detail examples will have descriptions of purpose.  We will describe project situations where advanced detail may be beneficial, and why it would be beneficial.

Project design model scope decisions

With this new structure of design model standards, Regions will work within the Level of Detail definition framework to define the scope of design model development for their projects.  The design model scope decisions will be made at the beginning of the PDS design effort, and documented using a simple scoping matrix that is similar to the table shown on this slide.  A project's design model scope can be updated as unanticipated project needs become apparent while the design progresses. The base level examples that are the statewide minimum design requirements will often be less detailed than many designers' expectations today.  This is because we are lowering expectations for design model detail in the mandatory statewide requirements.  The standard will have the higher detail model examples to allow for elevated model detail where and when a project needs it.  The decision to elevate model detail for a feature will no longer be a uniform decision applied to all occurrences of a feature on all projects across the state, instead the decision will be made at the project level based on project needs.  The decision to elevate detail for an element wouldn't have to be uniform within a project either, it could be varied from one occurrence of a feature to the next.  For example, a project may have 3 bridges to construct, but perhaps only 1 bridge falls within an area that is highly sensitive to project impacts.  The design model scope could elevate detail requirements for the design model at that 1 bridge while leaving the other 2 bridges at the base level. 

"Right-size" the design model effort

Let's reexamine the 3 measures that our new design model standards will use to address Right-Sizing concerns. 

1. The design model Features Example library will bring options for defining design model Level of Detail scope down to the feature level for each project, and it will offer multiple Level of Detail options for some of the features.  The default base level of detail standard, which will be the statewide minimum, will require less surface model detail than today's design model standard does.  The advanced detail examples for many features in the library will create options for Regions to specify elevated levels of detail within a project when appropriate.   These characteristics of design model Features Example Library create the flexible standards framework that can be adapted to specific needs of projects.
2. Regions will have more control over the scope of the design model development effort on their projects under this new standard.  The inventory of roadway features in the example library will be organized in a simple matrix that Regions can use to document design model scope decisions.  It is this scope decision making process that is facilitated by the Example Library that will allow Regions to elevate design model Levels of Detail when project needs justify the extra design effort.  These design model scope decisions will be made within Regions where the needs of each project are best understood. 
3. Finally, the Example Library will improve communication of design model delivery expectations by its use of 3D surface models as the language to communicate Level of Detail concepts.  With 3D model based definitions of how models should represent different features, and with the design model scope matrix that documents decisions for applying the standard to projects, designers will have a much better understanding of what they must deliver and how it should be shown in the model.

What is next?

We will be sharing information about this proposal for restructuring our design model standards through our Civil 3D knowledge base, and we will post implementation status updates there as well.  Email will be one channel for people to provide comments and ask questions.  As we see patterns or themes in the feedback we receive, we will use the C3D knowledge base to share those common comments and questions, and our responses to them.  We will be discussing this proposal with region offices, our consultant roadway designers, construction contractors, and other industry partners where and when we have the opportunity, such as at Civil 3D user group meetings, conferences, and workshops.

As we are receiving this valuable feedback on the standards concept as, we will also be producing our base level of detail examples that we will propose as the statewide standard of minimum level of design model detail.  Those base examples will be released incrementally for review as they are developed. 

We will also be asking our roadway design community to share their ideas about representation of features at various levels of detail by asking them to send us examples of roadway design work.  We will review the examples we receive, look for common themes and best practices, and standardize them into advanced detail examples that will be shared for broader review and ultimately incorporated into our design model Features Example Library. 

As we move through this standards development process we will share updates on our progress, on comments we receive, and on concept changes through a variety of communication channels including user group meetings, video releases, internal management meetings, etc.  If this standards concept stays largely intact after receiving input from the roadway project community, we expect to have the standard ready for FDM publishing in 2019.

Thank you for watching Part 1 of our design model standards update presentation.  Part 1 was a summary of the major components of the proposed update to our standard.  If you would like to hear more detail about how the proposed restructuring Wisconsin DOT's design model standards would be applied, and how it would benefit our WisDOT roadway projects, please proceed to Design model standards update (part 2) #design2 of the presentation.

Questions and comments regarding design model Standards should be sent by email to Brad Hollister at Wisconsin DOT.

dsn-mdl-stnd-updat-02.mp4 23:59

What follows is Part 2 of a two-part presentation that describes a proposed concept for restructuring Wisconsin DOT's design model standards that will help us achieve our goal of right-sizing design model delivery efforts.  Design model standards update (part 1) #design is an overview of the main elements of the proposed restructuring.  In Part 2, we will look more closely at the details of how the proposed standard would work, and how it would benefit our Project Delivery environment.  If you haven't watched Part 1 of the presentation, please do so before continuing with Part 2.

In Part 2 we will discuss:

• What exactly is a design model feature example?  What does each example contain, and why?
• We'll explain in greater detail how the design model Features Example library will improve communication of design model standards and other aspects of roadway design.  what the benefits of improved communication will be
• We'll identify other types of benefits the implementation of this standard will help us realize.

What is a design model feature example?

The DTM and Breakline components of a design model feature example will be the information that tells designers what must be delivered.  The DTM and breaklines will be referenced by the FDM as part of the definition of delivery requirements, and will communicate important details about the structure of the design model such as the location and configuration of breaklines, density of elevation points, and other 3D geometric information that is most easily communicated with 3D objects.  Designers will certainly benefit from seeing the structure and configuration of breaklines in the design standard, it will help them understand what should be delivered with the final design.

The source Civil 3D design data will not be part of the FDM design delivery requirements.  The source design data is supplemental information provided to show designers how the example was developed, and may be helpful to them in developing and improving their roadway design workflows.  Even though the examples can convey workflow ideas, the primary purpose of the examples is to communicate geometric requirements of design model delivery, and examples may not have been developed using the best, most recent Civil 3D design workflow concepts.  We will maintain models so they are current with design deliverables needs, but we will not maintain examples to stay current with latest application of new tools and workflow ideas.  Our Civil 3D training found in the Civil 3D knowledge base will continue to be our source for Civil 3D workflow ideas, and over time we will have an opportunity to develop training that is specific to feature example concepts.

Many feature examples will be accompanied by a supplemental narrative containing information about what elements of the feature are more important to develop precise and accurate detail for.  For each advanced detail example, the narrative will also explain how the additional model detail might benefit a project, and what types of project situations would be appropriate for considering setting design model scope above the minimum level of detail.

Feature level scope definition benefits

When implemented, this standard will provide a design model scope document in the FDM that lists all model features in the example library and their different levels of detail. The design model scope determination should be accomplished early in the design effort, perhaps during design contract negotiations for our consultant designed projects, and in a similar timeframe for our DOT designed projects.  The design model scope document should be retained as a record of design delivery expectations, and will be a required item in Construction Data Packet deliveries.

By defining design model scope at the feature level, project teams will be able to selectively apply higher levels of 3D design effort where it will be most beneficial, and lesser effort levels where the additional detail isn't as beneficial.  We will see variations in approach as Regions apply this design model standard against the backdrop of their office philosophies and past project experiences, but with this standards structure and associated design delivery content documentation, those variations in regional approach will become a strength of the new system.  With proper feedback mechanisms in place we will have an opportunity to learn more about the amounts of design effort associated with the development of different elements of our roadway models to varying degrees of detail, and we will also have opportunities to learn about the differences in project benefit provided by the various levels of detail for each feature.  Combining our increased understanding of design effort and project benefit, we will deepen our understanding of the appropriate role of 3D design practices on our projects, and continue to improve our design model scoping information to help us find the right balance between 3D design effort and project benefit – at the roadway feature level.

Feature-level based scope definition is a characteristic of the proposed standard is a key element that will help us achieve our goal of right-sizing the design effort to our many variations of project situations. 

3D models improving communication

As discussed in Part 1, we believe the model feature example library will significantly improve communication of design delivery expectations.  The DTM surface and breakline components of feature examples will provide significant improvements in how we communicate design delivery requirements. 

But examples will communicate more than what must be delivered.  The library will also help advance our discussions and designer's understandings of how design models are being used.  Not all pieces of the model are of the same importance, some areas of a model are acceptable with reasonable degrees of inaccuracy while other areas may be critical to have precisely accurate design information, and the examples can serve as a source for that type of information.  As an example, think about the earthwork cone that is constructed to support a bridge abutment.  Depending on the situation, we may not need highly detailed earthwork models around the wingwalls to adequately communicate the design concept for a construction project's needs.  But in front of the abutment where slope paving will be placed, now that is an area of importance to get the design developed correctly and to a high level of detail.  This is because the bridge abutment might be constructed early in a project's construction sequencing, before many of the surrounding roadway features are built.  A contractor will want to get the slope paving constructed before the bridge girders are placed, while heavy equipment can still access the slope paving area.  If the design geometry between the earthwork cone and the roadway features beneath the bridge has inaccuracies and those problems aren't discovered until after girders are set, reshaping the slope paving area without heavy equipment access is not going to be a fun task.  So, you can see why it would be important to invest extra design effort to ensure the slope paving design geometry is highly detailed and accurate, a small investment in the design process that can prevent significant construction issues.  The design model standard we are developing will account for the importance of detailed, accurate slope paving geometry, and the associated documentation will help our designers understand why.

The design model features example library and the enhanced communication of ideas that are inherent to 3D design objects can be used as a centerpiece for these types of discussions.  We will include a narrative article with many of the examples in the library, sharing our ideas about where the most critical areas of the design are, and why.  For the advanced detail examples, we will describe project situations where designing above the base level of detail may be beneficial, and how projects would realize those benefits.  So, you can see that the example library will certainly improve designer's understanding of WisDOT design delivery expectations, but it can also help facilitate deeper conversations about the relationship between roadway design and construction operations, and that will bring process improvements to project delivery processes.

Improved communication of design delivery expectations will:

1. Reduce excess design effort that can occur in the absence of effective communication.

   With today's FDM design model standards language as the only information source, roadway designers are wondering how much detail they should develop in their proposed work surface models.  Have they done enough?  How do they know?  Many people, being the conscientious engineers that they are, will take a conservative approach and develop high levels of detail throughout their surface models, perhaps more detail than is necessary or beneficial to the project.  It isn't only the design work that may be expending extra effort, just the level of detail decision-making process itself is requiring time and effort.  Designers are asking these questions and making their own determinations on each design model delivery.  The lack of clear communication of delivery expectations is costing us design effort.  The Model Features Example Library will resolve designers' questions about how much detail is necessary.

2. Help standardize representation of features in models across all WisDOT design deliveries (similar to our goals for plan sheets).

   With designers left to make their own final determinations about representation of common roadway features in their proposed work surface models, it isn't surprising that the result is a variety of different solutions.  The same types of features can look different from one design model to the next.  Long ago we recognized the benefits of standardization in our design output, and accordingly standardized plan sheets are a bedrock principle of all our Civil 3D roadway design and plan production workflows.  Standardization across our design model deliveries will benefit projects in much the same way, and the model feature example Library will be a strong step in the right direction for achieving that type of standardization.

3. Promote increased efficiencies for contractors.

   Consistent representation of roadway features in our design models will allow contractors to develop more consistency in their construction model development workflows.  Once roadway project features are represented with the same type of geometry and breakline configuration repetitively, contractors will become more efficient in the use of our design model data. 

   Another efficiency contractors will realize is the improved communication of design intent.  Just like our plan sheets, when models communicate the same type of information in the same manner on all of our projects, interpretation of that design information will be more consistent and will require less effort.

   By including the design model scope document with Contractor Data Packets, contractors will have immediate information on the expected content and level of detail of our design model deliveries, and will be able to plan their project activities accordingly.  With clear documentation of design delivery expectations, we will have an opportunity to ask contractors for their assessment of how well the design delivery met those expectations, and where it may have fallen short.  This would provide valuable feedback to designers, and also to the Department in our assessment of 3D design proficiency amongst our roadway design community.

4. Reduce design detail expectations

   The communication abilities of the Model Features Example Library will help us reduce level of detail expectations of our design models.  For many features, the base level of detail requirements, which are the statewide minimum detail standard, will be less detailed than many of our roadway designers might expect.  In large part, this is because WisDOT is no longer trying to deliver 100% Construction Ready surface models with our design deliveries.  100% construction ready surface models was a goal we established early in our Civil 3D implementation, and it heavily influenced how we taught roadway design in Civil 3D.  At that time we were thinking the role of a design model should be similar to the Plan, developed by the roadway designer as a static document that is used in construction, and therefore it needed to be developed to a sufficient level of detail to support our contractors' most advanced implementations of AMG technology and other model based processes.  But through our project experiences we've learned there is no single design model concept that is 100% construction ready for all of our potential contractors on all of our projects, many contractors will have different methods of feature representation that have become standard practice in their organization, and they don't want to change the way they are doing their work.  Contractors want a design model delivery they can use in the development of their construction models, but is flexible enough to be customized to their specific methods of operation.  So, we are now thinking about the purpose of the design model differently.  We no longer see it as the Plan-like rigid document that cannot be modified, instead we see it as a collection of geometric roadway design data that can be used by contractors in many ways.  The DTM component of our proposed work surface models is most useful to our contractors pre-bid for project exploration, planning, and analysis.  But for construction operations, many contractors will utilize our design model breaklines to help them in the development of their construction models, which they configure specific to their implementation of Automated Machine Guidance.  With this changed understanding of design models' role on our projects, highly detailed design model representations of features is not as critical, and often times less detail is sufficient.  But many of our designers still perceive that highly detailed and accurate DTMs in our design models are needed, the Model Features Example Library will help correct that misunderstanding.

Base requirements that emphasize construction benefits, option design benefits

As we are making decisions about the appropriate level of detail in the base design model standard, a concept goal we'll be keeping in mind is we would like the base delivery requirements to emphasize 3D design content that benefits construction projects.  When the feature's detail is more beneficial to design processes and not as beneficial to construction, we'd like to make the development of that type to be an advanced feature example, and not a base requirement, allowing project teams to use judgment on whether or not that added level of detail for the feature should be developed into the model.  There may be exceptions to this concept goal in our final standards, but it is a general principle we are using to guide us through these decisions.

An example that demonstrates this concept goal is design model representation of slope paving around abutments.  We talked earlier about why highly detailed and accurate design information for slope paving installations is a risk reduction measure that helps prevent construction project issues.  Slope paving areas are a good example of a situation where investing a little more design effort delivers construction project benefit, and our base standards will require detailed representations of slope paving to be incorporated in design models.

Curb ramp model features are the opposite type of example, they are a model feature that primarily benefit design processes, at least in today's construction project environment.  So far, we just don't see use of curb ramp models in construction operations, and curb ramp construction detail drawings in our plans are our primary means of communicating design intent for curb ramp construction.  A curb ramp model delivery typically will not benefit the construction project, but there is a design benefit to producing highly detailed and accurate curb ramp models.  Some designers believe that a model based design workflow is the most efficient way to develop an ADA compliant curb ramp design concept and the associated construction detail drawing needed to communicate that design.  The curb ramp modeling workflow you'll find in WisDOT's Civil 3D training is an efficient way of working through the iterative process of developing proposed grades and elevations that accommodate all the constraining elements found in curb ramp design, and with the resulting surface model output and intelligent Civil 3D labels, the path to plan sheets flows right out of the design.  Additionally, because of the automation involved, the Quality Control checking of plan content should be much simpler with the model based design approach.  However, other designers believe they can most efficiently develop curb ramp designs using manual methods to calculate design elevations and grades, and produce the curb ramp construction detail drawings using traditional CAD drafting techniques.  If they prefer to use that traditional approach to doing the design work, there would be no benefit to developing detailed representations of curb ramp and sidewalk geometry in their design model surfaces since that information would not be used in construction or design.  So, it makes sense to let the Region's design project team decide whether development of a curb ramp model is worth the added design effort, and not have a blanket requirement mandating curb ramp models in our base design model standards.

Design vs. Construction benefit is a concept we will consider as we think about specific roadway features and the level of detail that is needed in their design model representations.  When the design process is the primary beneficiary of advanced levels of model detail, the Region's design project team should have the authority to decide if that feature should be modeled to that advanced level.  When the construction project is the primary beneficiary and the project benefits justify the design effort costs, the base standards should require development of that feature's detail in design models.

3D design quality improvement

Implementation of this standard will elevate the quality of our design model deliveries.  When our design standards clearly communicate how features should be represented in design models, designers will have a benchmark to shoot for in design model development.  Design teams' 3D design quality control practices can be developed much more effectively, and the quality of our design deliveries will improve as a result.

Today's construction contract structure does not recognize our design model deliveries as contract documents, design models are provided for contractor's convenience and contractors assume risk when they use our design model data.  This is appropriate policy considering the current state of our design model implementation, and most contractors will invest effort to check our design model data before using it in their processes.  But when our design model implementation has matured to a state where we are consistently delivering accurate and standardized design models on our projects, the Department could consider elevating our design models to be part of our construction contract documents.  For that to happen, it is reasonable to expect that WisDOT will want to establish review and acceptance procedures for design models and incorporate those into our standard design review processes.  The clear definition of design model content requirements this standard provides will make such a program possible to establish.

Construction project feedback opportunities

Establishment of this standard will create opportunities for new types of feedback from contractors.  It provides the framework for conversations about benefits of added detail for different types of roadway features in different type of project situations.  WisDOT will gain valuable insight by engaging in these types of conversations with our contractors, and over time we can apply what we learn into improving our design model scope definition processes.  We will continue to improve our application of 3D design concepts on our projects, and as technology evolves and changes construction methods, we will have design standards mechanisms in place that allow us to adapt our design processes to future changes in project needs. 

WisDOT will also have an opportunity to establish mechanisms for receiving contractor feedback on the quality and accuracy of design model deliveries.  This kind of feedback would benefit designers, and more broadly could benefit the Department by helping us assess how well we are doing in meeting our goal for consistently delivering accurate models of standardized content.

Thank you for watching Part 2 of our design model standards update presentation.  If you haven't seen it, please watch Design model standards update (part 1) #design of this presentation as that is the overview of the major components of the proposed update to our standards. 

Questions and comments regarding design model standards should be sent by email to Brad Hollister at Wisconsin DOT.