Design model standards blog

On December 12, 2018, MDU led an ACEC Civil 3D Users Group webinar discussion about WisDOT design model standards. ACEC has posted a recording of that discussion, the link to that video is on ACEC Wisconsin Civil 3D Users Group webpage.

The design model discussion covers topics such as:

• Design model standards goals
  • "Right-sizing" the 3D design effort
  • Improve communication of design model delivery expectations
  • Address the over-extended role of roadway design
• Model features example library overview and utilization concepts
• Guiding principles for defining Base Level of Detail (Base LOD) standards. These include:
  • Reduced model detail expectations, but retain high value detail
  • Require detail with high communication value of engineering design concepts
  • Require detail that benefits construction, option detail that benefits design
  • Develop sufficient detail to ensure geometric constructability

• A close examination of the DRAFT Base LOD Sill Abutment model example, and discussion about how the guiding principles of defining Base LOD are incorporated into this model (Note: DRAFT Base LOD Sill Abutment model example files will be available for download from the WisDOT C3DKB in February 2019)

  

Last updated: 2018-10-30

MDU recently led a roundtable format discussion on our Design Model standards proposal with attendees of the ACEC Wisconsin 2018 Civil 3D User Group Workshop on October 22, 2018. Prior to the workshop, the ACEC Civil 3D Committee facilitated a review of the Design Model Standards proposal and sent MDU the resulting questions and comments from ACEC membership. The focus of the October 22nd discussion was the ACEC comments, and MDU's reactions to those comments. Today's Design Model standards blog entry is a summary of the roundtable discussion.

Tip: MDU would like to send a big Thanks to everyone who participated in the pre-conference review, and also to those who participated in the roundtable discussion. Your feedback is appreciated and very much needed as we work towards our goal of finding the best, most appropriate uses of 3D Design practices on WisDOT roadway projects.

Opening comments from MDU

One concept addition to the Design Model standards proposal since the release of the videos in early September is the idea of releasing model feature examples as guidance initially, for an undetermined amount of time. A guidance period will give us time to see how effective the examples are in practice, and identify additional needs for the implementation. Because the model feature example library concept fits and is fully functional within today's Design Model standards. We may find we are able to fully realize the benefits we are trying to achieve with the Model Feature Example Library during a guidance status period, and this approach will allow us to build out the example library more quickly.

If you haven't heard about our Design model standards update, please review it in the C3DKB, the comments and responses below will be more meaningful if you understand the concept proposal. You may also find the Construction data packet overview to be helpful background information, in particular the discussion about purpose and intended uses of Construction Data Packet content including Design Models.

ACEC Comment #22 (Civil 3D project delivery requirements):

On a side note, is WisDOT still committed to requiring one delivery platform? Why not allow consultants to use a delivery platform that is compatible with WisDOT to provide consultants with the opportunity to be as efficient as we can be with the delivery platform that we prefer. In general our firms experience with C3D has been absolutely frustrating! It is costing us significant amounts of time, of which WisDOT is not compensating us for. WisDOT is looking for project efficiencies in every aspect of project delivery at this time. One of the most significant efficiencies that could be realized immediately by WisDOT would be to discontinue dictating the use of C3D and allow a consultants to deliver the program more efficiently with delivery platforms that are compatible with each other.

The Civil 3D Project Delivery Requirements conversation topic is outside the scope of the Design Model standards discussion. However, since we received the comment, MDU would like to respond by saying we think we should reexamine the reasons why Civil 3D Project Delivery requirements were implemented, assess status of our implementation goals and status of the industry in regard to those goals, and revisit that conversation with the roadway design community. Preparation for, and execution of, that type of process is going to require attention and effort from MDU, and we will have to fit it into our workload. Right now our higher priority is to make additional progress with this design model standards effort. To be clear, we are not saying we think WisDOT needs to make a policy change, we are saying it would be beneficial to revisit the conversation, and we will make preparations to do that at a future date.

ACEC Comment #1 (model features example library):

Who is generating the Roadway Model Library (will ACEC members need to be involved in this effort?)

MDU has primary responsibility for model example library development, and the roadway design community will have opportunities to contribute to the development of it. Most, probably all, Base LOD examples will be manufactured by MDU, and distributed in draft status for Region and industry comment. We will compile comments received and share our reactions to that input through the form of status updates on our Design Model Standards blog page in the C3DKB. Furthermore, initially completed Base LOD model examples will progress from draftstatus to guidancestatus after initial waves of review and commenting are addressed. We will monitor effectiveness and feedback comments while examples are in guidancestatus for an undetermined period of time. Our goal is to achieve standards status ultimately, but it is too early in the process to set a timeline for that final step. The model example library concept should be very effective at achieving the goals we've set for it while in guidancestatus. Time and project experiences will help us determine when, or even if standardsstatus is a necessary step.

Roadway design community involvement, including consultants, won't be limited to review and commenting though. Once we have some initial examples released for review, we'll put out an open request for submission of Advanced Level of Detail (LOD) model examples. Industry participation will help us meet the Advanced LOD example needs of the Model Features Example Library more quickly. We'll standardize the examples we receive from the design community and redistribute them as draftproposals for industry comment.

ACEC Comment #4 (model features example library):

How was the feature list generated (is there room for adding/removing items/ different levels of detail?)

Absolutely. We'll get a few draftmodel feature examples released, and that will help deepen everyone's understanding of how the library will function. Following that we will publish our full list of features we intend to develop in the model feature example library, and anyone is welcome to send us their suggested additions. The library content can be added to at any time, but it will take time for the library to build out to a mature state.

Once the library is put into practice, we need to be careful about removing items. We don't want to affect projects mid-stream that may have incorporated example concepts, but certainly adding to the features represented in the library and improving current examples with new versions will be an absolute necessity if WisDOT is going to find the best role for 3D Design practices on our projects. We expect design model deliverables will be an evolving concept, it is not something that will remain static after initial implementation. We expect construction project needs will evolve, design systems' capabilities will evolve, and the model feature example library must stay current with those industry changes.

ACEC Comment #18 (model features example library):

Please consider providing one example of a feature and what it looks like at each level of detail. The level of effort versus level of detail is not linear based on the feature. An example, a low level of detail vs high level of detail for physical gores differs by a lot of effort. Low level of detail vs high level of detail for a simple/basic stretch of roadway (no curves, no superelevation, no beamguard, etc.) doesn't differ by much effort.

MDU agrees, level of effort is a complex question that will be vary for each type of feature, and will also vary by specific project situations. We should be able to identify general trends in effort levels, but hourly effort estimates will be difficult to determine and are not something MDU will develop with initial model feature example library releases.

MDU is working on Base Level of Detail (LOD) models now, and the first draftexample release will be TOP and DATUM surface models at an overpass structure abutment. With this initial DRAFT release of an abutment Base LOD model example, MDU will also develop an Advanced LOD model version to be used as a comparison. We will add more features to the library in the upcoming months, they will be released with their associated documentation incrementally as soon as each feature is ready.

ACEC Comment #5 (model features example library):

How do you determine what's basic and advanced, what features, models will look like? (The Model Library will probably play a role?)

The model example library and its supporting documentation will be our means of communicating that. Initial instance of draftBase LOD model feature examples are proposed by MDU, and will receive comments from an open review process. We are hoping to receive roadway design community and Construction Industry feedback before examples progress from DRAFT to GUIDANCE status.

ACEC Comment #9 (model features example library):

Model Examples Linked to the Spreadsheet both DWG and PDF could be helpful for gauging what will be needed.

We agree. PDF or some other means for non-Civil 3D users to be able to navigate model space and review the 3D objects, ideally without any special software install. MDU is working on that.

DraftBase LOD examples will generally include the following:

• FDM Construction Data Packet deliverables:
  • Surface models in LandXML
  • Surface model breaklines in ACAD DWG
  • Surface model boundaries in ACAD DWG
  • Surface model 3D Faces (TIN) in ACAD DWG
• Additional information for review convenience:
  • Civil 3D Design Data that produced the example
    Info:

    • The Civil 3D design data is provided for informational purposes only, it is not intended to convey Civil 3D project delivery requirements or design model delivery requirements.
    • Workflows used in the development of the model feature example may not be consistent with the latest and best MDU workflow recommendations.
    • Content and structure of the Civil 3D design data is not consistent with Civil 3D project delivery requirements, all model feature example design data will usually be delivered in a single Civil 3D DWG file. The design data is structured this way for convenience of sharing source data of our model feature examples.
  • Surface model contours in ACAD DWG
  • Surface model contours in 3D PDF
  • Surface model breaklines in 3D PDF
  • Surface model boundaries in 3D PDF
  • Surface model 3D Faces (TIN) in 3D PDF
  • Example Documentation
    • Base LOD documentation to identify critical design elements with background information
    • Advanced LOD documentation to include suggested purpose of advanced level of detail in specific types of project situations (why should a design team consider the elevated level of detail in design model scope?)

ACEC Comment #2 (design model scoping):

How will people scoping and reviewing project contracts be trained? (C3D KB Videos?)

Design contract scoping and negotiation is outside MDU's area of responsibilities and expertise. MDU must involve Regions, BPD Consultant Services Section, and perhaps additional stakeholders within the Department in the identification of training needs and determination of how to best meet those needs. We have not done that yet, it is a future need to address during this effort.

MDU intends to develop guidance documentation articles for advanced LOD model examples that describe the benefits of different elements of advanced LOD in the example and what types of project situations they are appropriate for. That type information is something MDU is in a good position to develop, and although it probably isn't the full solution that is needed, it will be an important and necessary part of the solution.

ACEC Comment #17 (design model scoping):

We like the idea of standardizing what features should look like, but have concerns with level of detail vs. level of effort interpretation. It's dangerous to think that a lower level of detail may require a lower level of effort, which intern will be interpreted to mean faster/cheaper by WisDOT PM's. Just because a low level of detail may be appropriate for a project doesn't necessarily correlate with a low level of effort. Cookie cutter roads and intersections are a low level of effort regardless of the level of detail because the program and workflows work as they are intended. Most designs though are not cookie cutter. Consider construction staging, it isn't necessarily a feature but increases the level of effort and model complexity.

We agree with this comment. Project situations must be considered when estimating design effort. Roadway design is not cookie cutter. An Advanced Level of Detail (LOD) model feature representation may require less effort to design than what is required for Base LOD models (for the same feature) on other projects. And best application of design workflow concepts can substantially change for the same feature from one project to the next, there is no one way to develop the design that is best for all circumstances. This is a great comment, insightful.

Level of effort is not something MDU is estimating in the initial development of model feature examples.

Level of effort estimating will need to consider many things. For example, simply estimating effort to develop a feature's representation in the design model doesn't factor design process benefits that can be realized by developing some features to greater levels of detail. A curb ramp model requires effort and has limited uses in construction, but it can be an overall net gain in design process efficiency when factoring in the effort to develop curb ramp construction details. We think experienced designers will naturally do the design work in the best manner to support design process needs, and the Design Model deliverables shouldn't mandate extra model detail if the benefit is mostly on the design side.

ACEC Comment #19 (design model purpose):

Has there been any communication with the construction industry as to if the design models are actually used, and if so, to what level of detail they are being used? I've personally talked with a couple contractor's and they have indicated they are NOT using the models provided by WisDOT design and are creating their own models to fit their needs.

Every contractor has their own approach, there is no single way to achieve their goal of greater efficiency in construction operations. They are using different methods, they are innovating competitively. There will always be specific contractors with differing opinions and philosophies, or specific project situations that are contrary to general industry trends, so we would never argue with anyone who has heard that perspective from one of our contractors or has had the type of project experience that the commenter is describing. We are speaking to industry trends, and there will always be specific project experiences that are contrary to the general trends.

Regarding the first part of the question, asking if we have received input from the construction industry, the answer is Yes. We have been fortunate to be able to work with multiple WisDOT contractors, industry organizations, construction equipment vendors, and construction/contractor focused software developers over the past 10 years. We always have an open door for any contractor, equipment vendor, software developer, or other industry resource who would like to discuss our digital design deliverables, we are not trying to be exclusive with this type of interaction, we welcome it.

We've enjoyed a strong partnering relationship with WisDOT contractors who have volunteered their time to work with us on this effort, helping us understand what types of design information is most useful to their operations, and what formats for that information are easiest for them to use. Much of our engagement has been with earthwork contractors as the dominant use of design model data on our projects is in earthwork and aggregate placement operations. These interactions have ranged from remote questionnaires with written responses, to full day in-person meetings at contractors' offices with opportunities to see WisDOT design model deliverables used in contractor software for project analysis, construction model development, QC, and related types of activity.

Regarding the second part of the question, asking how (or if) our digital design data is being used, that answer depends on the contractor you talk to. Speaking to general industry trends, the instances of WisDOT design models being used directly in AMG operations are not common. The name we used for that direct use of design models concept was "100% Construction Ready Surface Models", and that was a goal for our design model implementation when it was first announced in 2011. Early feedback from contractors and project experiences convinced us that is the wrong purpose for design models in our project environment, and the 100% Construction Ready concept is no longer a WisDOT goal. The Base LOD model examples that define statewide delivery requirements will generally not be used directly in construction operations, they do not have enough design detail to be used in most contractors' AMG operations.

Our intended use for design models, and all Construction Data Packet information generally falls under 3 categories. 1) pre-bid and post-bid project analysis and planning, 2) construction model development and QC, and 3) construction staking. We encourage anyone who may be looking for more information on the intended uses of our Construction Data Packet content, including Design Models, to review Construction data packet overview in the C3DKB, found under Digital data.

ACEC Comment #20 (design model purpose):

The text discusses using the design model for AMG. Has this been tested/attempted with C3D? We have staff in Illinois that are having trouble with processing the data needed for an AMG ready surface on an Illinois Tollway project, using MicroStation. They basically need cross section "cuts" every 2-inches along the entire corridor. Horizontal and Vertical tangent sections process quickly, but as soon as curvature is introduced, specifically vertical curvature, the processing is very slow and time consuming. Our experience has been that microstation is much faster than C3D so we can only imagine how much time this processing may take in C3D.

We are interpreting this comment to be based on the idea of direct use of the Design Model in AMG operations, the 100% Construction Ready Surface Model concept. It was not our intention to communicate that as the purpose of Design Models in the design model standards videos. We were thinking that way 7 years ago, but we are thinking about it differently now. We will not be requiring full roadway Design Model deliveries developed to that level of detail, we believe that practice is not a good fit for our project environment. Contractors needing that type of model detail for their operations can use our Design Models as a platform to build construction models from, or as a source of data for QC of their construction models, and those are the types of AMG uses of our Design Models that we've encountered most often.

ACEC Comment #16 (design model scoping):

It seems the guidance leaves a lot to interpretation. Thus the WisDOT Project Manager may have different expectations than the Consultant at the time of scoping the project. Scoping and fee development will be critical because of this. Has there been consideration for removing this "individual interpretation" to provide "standard guidance" such as creating a matrix of anticipated modeling effort to help WisDOT and Consultant Project Managers understand the hours to be scoped for various levels of design models?

As a scoping aid, MDU will develop a simple matrix that lists model feature scope options with links to our C3DKB guidance documentation, this MDU guidance will not estimate design effort levels. We hope to receive feedback when our scoping aid and additional guidance is put into practice, and we will consider how well things are working and continue to refine the system and develop additional guidance information based on the feedback we receive. We expect immediate process improvement with the model example library concept, we don't want to wait for the effort level estimating solution to be developed before we realize the benefits of better definition of deliverables through the example library.

In addition to the MDU guidance, we have future plans to incorporate estimated effort levels that are coordinated with the example library into the MasterWorks work breakdown structure for design contract negotiations.

ACEC Comment #6 (QA, QC, and design delivery acceptance):

Who is checking models after submitted? Now that we will know what level of detail is needed we still need to validate it.

There is no formal review process for acceptance in place. It would benefit this implementation if we were to establish a review process for design deliveries, and Regions may choose to consider that, and we would help and support them if they did. The Bureau of Project Development is not considering applying resources for statewide review and acceptance of Design Model deliveries on a project by project basis. However, a model review and acceptance program will be easier to establish with improved definition of deliverables, so the Model Example Library implementation work is a prerequisite to that sort of program.

MDU has developed QC guidance for design project team review of their own work. That documentation is at Civil 3D QC surface checklist, and may need updating to remain consistent with concepts introduced by the Design Model standards implementation. The QC guidance will be updated as needed as we progress in this implementation.

ACEC Comment #3 (design model scoping):

We envision the Consultant taking the first stab at what deliverables will be needed during contacting? Review and Revise with DOT Staff?

Regions, Consultant Services Section, and perhaps other stakeholders need to get involved in that conversation. Other groups within the Department will need some time to get familiar with the Design Model standards proposal, they haven't had an opportunity to work with us on this concept yet.

ACEC Comment #10 (design model scoping):

Is there a way to expediate the contracting spreadsheet, tying overall project type to a minimum level of detail for the items needed.

We've considered mapping Design Model scope to project type, but we struggled with defining a project type based standard in a way that provides the needed flexibility. Tying Design Model scope to project situations that consider anticipated construction operations, environmental sensitivities, challenges of design fit into existing condition, etc. just worked better for our goals of applying 3D Design processes to our project environment. We believe a feature-based approach to defining design model scope will allow project teams to be more effective in prescribing the appropriate amount of design effort to the variety of project situations encountered on projects of the same improvement type.

ACEC Comment #11 and #12 (design model scoping):

Contract Spreadsheet looks a lot like the Utility Spreadsheet (which was cumbersome at first but now used all the time!)

Delivery Model Examples will need to happen in conjunction with the spreadsheet.

We haven't developed a Design Model scoping aid yet, the slide displayed in the Design Model standards video was showing something that was quickly developed to communicate a concept. We're not sure what a Design Model scoping tool will look like yet, or the details of how it will be used, but we absolutely agree it must be synched with model example library content.

ACEC Comment #14 (design model scoping):

Part 1 of Videos: If the standards are set during scoping process, what happens if the contractor or region reviewers request additional detail? Modifying the model could be very difficult and time consuming at the end of a project.

That would be a project team discussion as to how to handle, and existing policies and practices for design contract administration would apply. Our scoping process aids and model example library will benefit those situations because of the added documentation and better definition of initial design delivery expectations.

We agree that in most cases the overall design effort will be less work if the need for higher levels of detail in model elements are identified early in the design process. Late design model scope changes that increase level of detail may require rework and an overall greater design effort than when the higher level of detail scope is set early.

ACEC Comment #15 (design workflow):

Part 2 of Videos: Could issues arise if Civil 3d elements are eliminated from the library that are used in the examples? Will DOT always have legacy items that will always be able to be used? Example would be the new abilities of the DOT daylight subassembly be used in the example but not be available in future releases.

Interesting question, and we can see how that could possibly happen. We are thinking about the abilities of our design system when we are setting delivery requirements, and we are thinking about our delivery requirements when we identify and address functionality needs/changes to our design system. We want to avoid making changes to our Civil 3D tools that make delivery requirements harder to achieve. If we miss something and that would occur, it would be a high priority in our Civil 3D work to fix it.

Also, the model example library defines deliverables, but does not require specific workflows as to how to develop the deliverables. A subassembly used in the development of one of the models might be changed or retired, but the functionality to achieve the results should still be available, although perhaps differently. Workflow and delivery requirements have relationships to each other, but are not rigidly locked to each other.

ACEC Comment #13 and #21 (curb ramp modeling):

We don't have to model Curb Ramps if we don't want too!

It is GREAT to see the text that curb ramps will not be modeled.

These comments are encouraging to hear! We also think they demonstrate that better definition of our design model standards is needed and will be beneficial. Curb ramps have never been required design model elements in our FDM standards, the FDM has always said curb ramps are optional features for designers to consider adding to models. However, our Civil 3D training shows people how to model curb ramps because some projects have found there are design benefits in doing so. So in this case our C3D workflow training has gotten mixed up with our FDM delivery requirements, and it is a common misunderstanding that extends to many others besides these 2 commenters. We think the model example library is going to be an effective way of creating better, easier to interpret definitions of design model delivery expectations, and will help us resolve these types of misunderstandings.

ACEC Comment #8 (design workflow, or design model scoping):

There will still need to be an emphasis for getting the correct level of detail early on the project to minimize escalating design levels as the project nears completion.

If we interpret this comment as being about workflow, we think it is an effective design workflow strategy, but it needs to be applied with a balanced approach. If the roadway alignment/profile are still unsettled, investing too much time in detail development is risking lost effort and rework. It's a project by project consideration. But certainly, pushing the design detail early rather than waiting until PS&E will have design process benefits.

If we interpret this comment as being about design model scoping we agree that in most cases the overall design effort will be less work if the need for higher levels of detail in model elements are identified early in the design process. Late design model scope changes that increase level of detail may require rework and an overall greater design effort than when the higher level of detail scope is set early.

ACEC Comment #7 (contractor use of digital design data):

Is there going to be requirements for contractors to keep up with software/use data? Sometimes contractors still don't see the benefit with smaller jobs.

We interpreted this question a couple ways, so we have 2 answers that are based on 2 different interpretations.

1. We won't have any requirements in place for contractors to use specific software, or to use specific types of data. Contractors will continue to determine their means and methods
2. Design and construction processes will evolve as new technology and applications of ideas emerge. Maximizing the value of our design work is the goal, and to achieve that goal we are thinking about the solution as a moving target. MDU will continue to work with the construction industry to assess the effectiveness of our design deliverables. We've benefitted from the voluntary involvement of many terrific partners from the construction industry, and we expect that to continue.

ACEC Comment #23 (Civil 3D development):

Continue to improve and provide more efficient workflows to generate plans and deliverable.

Yes. With the help of our user base, MDU will continue to assess the effectiveness of our Civil 3D build and improve the tools for WisDOT project types. We will also continue to communicate our functionality needs and ideas to Autodesk to promote solutions that are best realized in the core software.

ACEC Comment #24 (design modeling and EG design survey):

Deliverables are based on the level of quality/detail of existing conditions. If the existing DTM has low frequency, the design deliverable should roughly match the interval.

This commenter has identified an important concept. The relationship between design survey accuracy/density and design modeling practices is a topic that is worthy of extended discussion. There is a lot to think about, much more information than we'll attempt to communicate in this blog post, but we'll summarize our thoughts here and look for future opportunities to have a greater discussion on the topic.

The effect of EG existing ground accuracy and/or density on design model development is dependent on the type of design work. In general, a less dense or less accurate EG will do the greatest damage to design concept integrity at the match points of the design.

For simple reconstruct design scenarios, it is usually the accuracy of proposed slope intercept locations that are most affected. As you move further inside the footprint of proposed work, the negative effects of a less dense and/or less accurate EG are less substantial, and the value of higher levels of detail in the design model is preserved.

For more complex retrofit design situations where fitting the design concept into existing terrain conditions is a more complex challenge, it is still the match points between proposed work and EG that are affected, but the effects can be more detrimental to the overall design concept. For example, let's consider a shoulder widening operation with a longitudinal match to existing pavement along the edge of traveled way. In this situation, it is the existing pavement profile that controls the complete roadway design solution. Every cross sectional feature, every proposed work offset/elevation label on the plan cross sections, is a projection from the existing edge of pavement. The integrity of the entire roadway design is entirely dependent on the accuracy/density of EG at the edge of pavement matchline. If this is understood and accommodated in the design survey collection methods, the design can be effectively developed. If it is not accommodated in the design survey collection methods, serious design concept flaws can result, leading to significant construction project issues.

Designers need to consider the design survey collection methods used on their projects, and determine if EG accuracy/density will sufficiently meet design project needs. Awareness and understanding of the commonly used survey collection methods, the strengths and weaknesses of the resulting survey data is a critical skill for effective roadway design.

MDU is developing workflow concepts to improve the communication of design survey collection methods employed on a project. Improving communication of survey collection methods to designers and to contractors will improve processes help project teams avoid costly construction project issues.