Intelligent Transportation Systems

T3 Webinar:

Incorporating Systems Engineering into your Business Plan

August 2, 2007

Text version of Webinar presentation:

"Understanding Where it Fits in Your Agency"

Description of image or images on a slide contained in brackets.

Back to Webinar Files

Systems Engineering: Understanding Where it Fits in Your Agency

Presented by:
Emiliano Lopez

Talking Technology & Transportation (T3) Webinar
August 2, 2007

Slide 1: Presentation Overview

  • Purpose
  • Background
  • Systems Engineering (SE) in the Process
  • SE Challenges and Recommendations
  • Conclusions
  • Resources

Slide 2: Purpose of Session

  • Illustrate where, in an agency.s business processes and practices, to consider systems engineering
  • Illuminate challenges to including systems engineering
  • Provide recommendations on inclusion of systems engineering in your processes

Slide 3, 4, 5, 6, 7: Systems Engineering Background

  • National need for quality assurance and control in the ITS project delivery process
    • Planning
    • Deployment
    • Operations and Maintenance
  • Federal philosophy on SE and ITS Projects
    • Make sure, place and time, the right system is proposed, implemented AND delivered on time and within budget
  • ITS Final Rule Key Legislative Points
    • Regional Architecture Development
    • Use of ITS standards
    • Use of Systems Engineering in the project delivery process (23 CFR 940.11)

Is Systems Engineering Really New To Transportation?

Not Really

U.S. Interstate Highway System built using many systems engineering principles

  • Systems Engineering and the Interstate
    • Started with a vision of the needs the interstate system would provide for
    • Required planning and stakeholder collaboration
    • Set requirements and standards for seamless connectivity
    • Led to design expectations and quality control and assurance
    • Incorporated operations and maintenance

Slide 8:

"Many local programs are modeled after the same project delivery process used to build the Highway Interstate System"

Slide 9:

"Systems engineering may already be part of your Agency's business processes"

Slide 10, 11, 12, 13: Where to Consider SE

  • What is meant by "mainstreaming" and "integrating systems engineering into your business processes and practices
    • Evaluation and selection within your formal project planning/program funding process
    • Formally addressing ITS in your project delivery documents
  • Should address:
    • Project selection based on regional transportation merits and needs
    • Use similar quality assurance and control you apply on your traditional roadway projects
  • Ideally, systems engineering is specialized enough to have a separate group provide agency support full-time
    • For many agencies, frequency and level of ITS do not justify this level of support
  • Planning and Program Funding
    • TIP/STIP
  • Design
  • Procurement
    • Selecting the appropriate contract
  • Implementation
    • Consider O&M and system upgrades/retirement

Slide 15

[This slide shows the V Model. The V Model resembles the letter "V" with the addition of two wings extending from the top left and right of the V. The V is divided into 14 steps, beginning on the top left wing and ending at the right wing. The steps are in sequence and extend down the left side of the V, to the bottom of the V, and up the right side of the V. The steps, from left to right are:

  • Regional Architecture(s) (the lone step on the left wing)
  • Feasibility Study/Concept of Exploration
  • Concept of Operations
  • System Requirements
  • High-level Design
  • Detailed Design
  • Software/Hardware Development and Field Testing (the step at the bottom of the V)
  • Unit/Device Testing
  • Subsystem Verification
  • System Verification & Deployment
  • System Validation
  • Operations and Maintenance
  • Changes and Upgrades (the first step on the right wing) and Requirements/Replacement (the last step on the right wing and last step on the V Model).
Opposite the steps running down left side of the V is an arrow "Decomposition and Definition." Along the bottom of the V is an arrow "Timeline." Running up, along the right side of the V, is an arrow "Integration and Recomposition." Finally, arrows within the V connect steps on the left and right sides of the V, indicating a validation process of a left side step that take place in a right side step. From top to bottom:
  • Concept of Operations (step) opposite System Validation/Initial Deployment, where the link is the Systems Validation Strategy/Plan
  • System Requirements (step) opposite System Verification/Systems Integration, where the link is the Subsystem Verification Plan (Systems Acceptance)
  • High-Level Design/Subsystem Requirements opposite Subsystem Verification /Subsystem Integration, where the link is the Subsystem Verification Plan
  • Detailed Design (step) opposite Unit Testing (step), where the link is the Unit Test Plan
]

Slide 16

[This slide displays the overlap between the traditional transportation project model and the V Model. Across the top of the slide, the steps to the traditional model appear from left to right. The steps are:

  • Transportation Planning
  • Programming/Budgeting
  • Project Initiation
  • Preliminary Engineering
  • Plans, Specifications & Estimates
  • Construction
  • Project Closeout
  • Operations & Maintenance
  • Changes & Updates
  • Retirement/Replacement.
Below the traditional model appears the V Model. The V Model resembles the letter "V" with the addition of two wings extending from the top left and right of the V. The V is divided into 14 steps, beginning on the top left wing and ending at the right wing. The steps are in sequence and extend down the left side of the V, to the bottom of the V, and up the right side of the V. The steps, from left to right are:
  • Regional Architecture(s) (the lone step on the left wing)
  • Feasibility Study/Concept of Exploration
  • Concept of Operations
  • System Requirements
  • High-level Design
  • Detailed Design
  • Software/Hardware Development and Field Testing (the step at the bottom of the V)
  • Unit/Device Testing
  • Subsystem Verification
  • System Verification & Deployment; System Validation
  • Operations and Maintenance
Changes and Upgrades (the first step on the right wing) and Requirements/Replacement (the last step on the right wing and last step on the V Model).

Opposite the steps running down left side of the V is an arrow "Decomposition and Definition." Along the bottom of the V is an arrow "Timeline." Running up, along the right side of the V, is an arrow "Integration and Recomposition."

Finally, four broken lines drop from the traditional model at the top of the slide to various steps on the V Model, indicating the parallel processes on both models. A line drops from Project Initiation on the traditional model to Concept of Operations on the V Model; from Preliminary Engineering to Systems Requirements; from Plans, Specifications, and Estimates to Software/Hardware Development and Field Testing; and from Construction to System Validation.

Slide 17: Systems Engineering Challenges

  • Institutional
    • Attitude that systems engineering is new. "Our way of doing it is fine"
    • Others within or among agencies may need assistance
  • Resource Management
    • Knowledge and time. "Staff has enough to do without having something new to learn"
    • Long term operational and maintenance considerations
  • Support
    • Contractor and professional services also just learning about SE

Slide 18: Recommendations

  • Have a vision for your ITS projects/programs
  • Know what you have first
    • SE Process Improvement Review
  • Use existing processes if possible; modify as needed
  • Risk management is key
    • Secure the right resources
    • Establish formal processes
      • When possible apply existing ones to ITS
      • Be prepared to add additional elements

Slide 19: Conclusions

  • Systems engineering is already being done by many agencies
  • Political, management and staff turn-over is inevitable
    • Institutionalizing systems engineer will reduce risk of selecting ITS projects that don't meet their intended need and end up over budget and late

Slide 20: Resources

Slide 21: For Presentation Information

Emiliano Lopez
Gateway Team Member
FHWA - Office of Operations
emiliano.lopez@fhwa.dot.gov
202.366.2199

Access T3 Archives at: http://www.pcb.its.dot.gov/res_t3_archive.asp?Archive=True



back to top