1. ITS ePrimer Module 2: Systems Engineering September 2013 Intelligent Transportation Systems Joint Program Office Research and Innovative Technology Administration, USDOT

2. 2 U.S. Department of Transportation Instructor Bruce Eisenhart Vice President of Operations Consensus Systems Technologies (ConSysTec) Centreville, VA, USA

3. 3 U.S. Department of Transportation Learning Objectives 1.Provide an introduction to the systems engineering process (SEP) and how to apply it to the development of ITS projects 2.Provide an overview of intelligent transportation systems (ITS) architectures 3.Review the role of ITS standards in the development process 4.Discuss the Architecture and Standards Rule and the role of Systems Engineering and ITS Architecture in addressing the requirements of the rule 5.Identify how SEP supports transportation planning

4. 4 U.S. Department of Transportation Introduction What is Systems Engineering? According to the International Council on Systems Engineering (INCOSE) Handbook (2007): "Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems."

5. 5 U.S. Department of Transportation What Is Meant by Interdisciplinary Approach?  The application of basic engineering discipline, management discipline, and expertise in whatever applications domain the system lies.  For ITS, the basic engineering discipline is Transportation Engineering. Source: “RITA: National ITS Architecture SE Process Improvement Presentation”

6. 6 U.S. Department of Transportation Key Concepts of Using the SEP The systems engineering process (SEP) seeks to:  Consider the entire life cycle of a system  Focus on stakeholder involvement  Understand the problem to be addressed  Address project risks as early as possible  Clearly document the process and the output of each step  SEP is scalable based on size, complexity, and risk of project

7. 7 U.S. Department of Transportation Benefits and Costs of SEP  Benefits  Improve the quality of products created by the project  Reduce the risk of schedule and cost overruns  Increase the likelihood that user needs will be met  Improve stakeholder participation  Provide better documentation  Reduce operational costs  Costs  SEP causes some reapportionment of cost with additional effort needed early in process and during verification

8. 8 U.S. Department of Transportation Systems Engineering Model for ITS: The “V” Source: Systems Engineering Guidebook for ITS, Version 3.0, FHWA and Caltrans, November 2009, www.fhwa.dot.gov/cadiv/segb

9. 9 U.S. Department of Transportation Regional ITS Architecture  First step in the SEP, occurring before project initiation  Consider how the system to be developed is described in the regional ITS architecture □ Regional ITS architecture is the plan for deployment of ITS in the region  This step identifies how the system fits into the regional plan for ITS

10. 10 U.S. Department of Transportation Concept Exploration  Perform initial feasibility, benefits analysis, or needs assessment  Evaluate alternative concepts □ Prior to initial investments  Provide justification for a project to move forward into development  Make the business case  Decision gate: Obtain management approval to proceed into the programming of funds phase

11. 11 U.S. Department of Transportation SE Management Planning  Development of SE Management Plan (SEMP) for managing the technical effort on a project □ Technical planning and control of the project □ Systems engineering processes to be used for the project.  2-stage process □ 1 st – SEMP Framework ▪Developed at project initiation □ 2 nd – SEMP Plan Development ▪Developed as project proceeds

12. 12 U.S. Department of Transportation Concept of Operations  Purpose of the Concept of Operations (ConOps) is to clearly convey a high-level view of the system to be developed that each stakeholder can understand  Answers who, what, where, when, why, and how about the system from the viewpoint of each stakeholder  User needs are identified at this stage Used with permission from the American Institute of Aeronautics and Astronautics

13. 13 U.S. Department of Transportation System Requirements  According to EIA 632, a System Requirement is “something that governs what, how well, and under what conditions a project will achieve a given purpose.”  Types of Requirements □ Functional: define “what” □ Performance: define “how well” □ Non-functional: define “under what conditions” Elicit Requirements Analyze Requirements Document Requirements Validate Requirements Manage Requirements Elicit Requirements Analyze Requirements Document Requirements Validate Requirements Stakeholder Participation Manage Requirements

14. 14 U.S. Department of Transportation High Level Design  Begin definition of problem solution □ Identify Subsystems and key Interfaces  Allocate requirements to Subsystems  Create a project level architecture  Analyze alternative designs Analyze alternative designs Evaluate alternative implementations e.g., Centralized Vs. Distributed e.g., Signs Detectors Comm Routing etc. Allocate Reqmts to Subsystems High Level Design Define Subsystems and Interfaces

15. 15 U.S. Department of Transportation Detailed Design  Define how the system will be built  Define components: hardware, software, database elements, firmware, etc.  Create procurement specifications  Design any custom hardware or software modules Existing Vendor Products? Select Vendor Products Yes Implementation Develop Detailed HW/SW Specifications Prototype User Interface No Detailed Design

16. 16 U.S. Department of Transportation Procurement/Development  This step involves hardware fabrication, software coding, database implementation  Existing Vendor Products are procured and configured  Concurrently, unit test procedures are developed to demonstrate how well the detailed design is met  At the end of this step, the system is ready for testing to begin

17. 17 U.S. Department of Transportation Unit Test  Hardware and software development are verified against unit verification plan.  Verify that the delivered components match the documented detailed design.  For existing vendor hardware/software, perform acceptance testing to show that the hardware and software meet requirements for the unit

18. 18 U.S. Department of Transportation Subsystem Integration and Verification  Integrate components and verify at the subsystem level using verification procedures  Verification occurs iteratively. Verify one subsystem before proceeding to the next. Integration Verification A B C D E Tested Components Interfacing Systems C E AB D Verified System Verified Assemblies C E AB D (2 nd Level) AB D C E (1st Level) AB D C E Source: SEHB, fig. 27, p.60

19. 19 U.S. Department of Transportation System Verification  Verification confirms that a product meets its requirements  Verification ensures that the product is built right  Two parts to verification: □ Factory Test—performed in a controlled environment □ On-site Test—performed in the operating environment, after system deployment  In all cases, verification procedures are followed

20. 20 U.S. Department of Transportation Initial System Deployment  System is installed in the operational environment  Transferred from the development team to the team that owns and operates it  Includes delivery of support equipment, documentation, operator training, and other necessary products to support operations and maintenance of the system  Perform burn-in or acceptance testing to uncover any issues in operational environment O&M Team Development Team Deliver System Prepare Facility/Site Install System Transition to Operations

21. 21 U.S. Department of Transportation System Validation  In-process and once operational □ At each step—are the right outputs defined  Once Operational—was the right system built? □ Validate that the system meets the needs defined in the ConOps In-Process Validation Requirements Feasibility Study Concept of Operations Design Implementation Operational System Right Business Case? Right Needs? Right Requirements? Right Design? Right Implementation? Right System? YES! Stakeholder Participation

22. 22 U.S. Department of Transportation Operations and Maintenance  System carries out intended operations  Routine maintenance is performed  Staff is trained  Longest phase: occurs until system is retired or replaced

23. 23 U.S. Department of Transportation Changes and Upgrades  Throughout the operations and maintenance process, changes and upgraded may be needed  Follow the entire SEP and update original outputs as needed □ Following the SEP ensures system integrity is maintained □ SEP may be abbreviated when making changes and upgrades

24. 24 U.S. Department of Transportation Retirement and Replacement  Eventually a system will either no longer be needed, or not be cost-effective to operate  May not be able to maintain □ e.g., component obsolescence  Analysis of retirement or replacement may mean implementing a concept exploration step again □ Then begin the full SE process for replacement

25. 25 U.S. Department of Transportation Cross-Cutting Activities  These activities are not associated with any one step of the SE Process, but occur throughout many or all steps Cross-Cutting Activities Project Management Risk Management Project Metrics Configuration Mgmt Traceability

26. 26 U.S. Department of Transportation Project Management  Management of cost, schedule, and resources to successfully complete a project  Closely related to SE; necessary to complete project  Provides supportive environment to development activities

27. 27 U.S. Department of Transportation Risk Management  Identify and control risks □ Identify problems before they occur □ Plan for the occurrence, and monitor to take early action when necessary  Steps □ Risk Identification □ Risk Analysis and Prioritization □ Risk Mitigation □ Risk Monitoring  Develop and update a risk management plan List Risks Determine Risk Likelihood Determine Risk Impact Plan for Top 10 Experts Project Participants

28. 28 U.S. Department of Transportation Project Metrics  Measures to track and monitor the project and expected technical performance of the system development effort  Determine if the project is “on track” from a programmatic (budget/schedule) and technical (SEP activities) standpoint Cost Progress 100%Physical % Complete EV Cost at Completion Actual Cost Budgeted Cost Budget Actual

29. 29 U.S. Department of Transportation Configuration Management  Process to establish and maintain consistency of a product □ Ensures system integrity is maintained  Components: □ Configuration Management Planning □ Configuration Identification □ Change Management □ Status Accounting  Process documented in SEMP or Project Management Plan

30. 30 U.S. Department of Transportation Traceability  Ensures that different outputs of the SEP process properly relate to each other  Centers on relationship of requirements to rest of project  Traceability must work backwards and forwards □ Each need in ConOps traces to a system requirement □ Design specifications trace back to requirements  Process continues through each stage of SEP.

31. 31 U.S. Department of Transportation SEP Summary  Covers entire life cycle of system  The process should be scaled for each system/project □ Not one size fits all! □ Small projects use less resources to address key steps or may combine steps □ High-risk projects require more robust SEP □ Define how SEP tailored for each system/project as part of SEMP

32. 32 U.S. Department of Transportation Related Topics Other topics that are closely related to the Systems Engineering Process  ITS Architectures □ National ITS Architecture □ Regional ITS Architectures □ ITS Project Architectures  ITS Standards  Applying the SE Process to Project Development  Transportation Planning

33. 33 U.S. Department of Transportation National ITS Architecture  Provides a common framework for planning, defining, and integrating ITS  The architecture defines: □ The functions that are required for ITS □ The physical entities or subsystems where these functions reside □ The information flows and data flows that connect these functions and physical subsystems □ View at http://www.iteris.com/itsarch/index.htm http://www.iteris.com/itsarch/index.htm

34. 34 U.S. Department of Transportation National ITS Architecture  The physical architecture identifies 22 subsystems (shown below)  ITS services are described in Service Packages, which represent slices of the architecture

35. 35 U.S. Department of Transportation Regional ITS Architectures  Regional ITS Architectures define the plans, programs, goals, and objectives for implementation of ITS within a more local scope □ Regional specific plan for the deployment and integration of ITS  Regional ITS Architectures use the National ITS Architecture as a template  23 CFR 940.9 defines the nine required elements of a regional ITS architecture

36. 36 U.S. Department of Transportation Regional ITS Arch – Rule 23 CFR 940.9 The regional ITS architecture shall include, at a minimum: (1) A description of the region; (2) Identification of participating agencies and other stakeholders; (3) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders; (4) Any agreements (existing or new) required for operations, (5) System functional requirements; (6) Interface requirements and information exchanges with planned and existing systems and subsystems; (7) Identification of ITS standards supporting regional and national interoperability; and (8) The sequence of projects required for implementation.

37. 37 U.S. Department of Transportation Turbo Architecture  A software tool that automates creation of a Regional/Project ITS Architectures using the National ITS Architecture National ITS Architecture City Transit Ops Center City Transit Ops Center City Traffic Mgmt Center City Traffic Mgmt Center City PWD City Transit Regional/Project ITS Architectures Transit Management Traffic Management

38. 38 U.S. Department of Transportation ITS Project Architectures  Provide a high level view of a project focusing on the systems, interfaces, and information flows relevant to the project  Typical output of the High Level Design step  Essentially a subset of the Regional ITS Architecture, which is relevant to a specific project; can be used to meet requirements of 23 CFR 940.11 Regional ITS Architecture

39. 39 U.S. Department of Transportation ITS Standards  ITS Standards define how ITS systems, products, and components can interconnect, exchange information, and interact to deliver services within a transportation network  Ensure interoperability between products of different manufacturers  Types of Standards □ Data transferred on an interface □ Communications protocols used to send data □ Hardware specifications  More about ITS standards can be found at http://www.pcb.its.dot.gov/stds_training.aspx http://www.pcb.its.dot.gov/stds_training.aspx

40. 40 U.S. Department of Transportation Using the SEP for ITS Project Development  SEP is an extension of the traditional project development process, with the same major steps □ Project Initiation □ Preliminary Engineering □ Plans, Specifications, and Estimates □ Construction □ Project Closeout

41. 41 U.S. Department of Transportation Systems Engineering Analysis Requirements  23 CFR 940.11 defines seven requirements for all projects receiving funding via the Highway Trust Fund.  Level of detail of the analysis should be commensurate to scope of the project. □ Higher risk projects require a more detailed analysis.  The federal requirements are closely aligned to the SEP.

42. 42 U.S. Department of Transportation 23 CFR 940.11 Requirements The systems engineering analysis shall include, at a minimum: 1)Identification of portions of the regional ITS architecture being implemented; 2)Identification of participating agencies roles and responsibilities; 3)Requirements definitions; 4)Analysis of alternative system configurations and technology options to meet requirements; 5)Procurement options; 6)Identification of applicable ITS standards and testing procedures; and 7)Procedures and resources necessary for operations and management of the system.

43. 43 U.S. Department of Transportation Relationship to Transportation Planning  The outer parts of the SEP “V” Diagram fit within the structure of the transportation planning process.  Long Range Transportation Plan (LRTP) for a state or MPO contains transportation projects that may be undertaken in the medium or long term.  Transportation Improvement Program (TIP) contains projects that will be undertaken within four years.  The Concept Exploration Phase of the SEP can provide input to both the TIP and LRTP.

44. 44 U.S. Department of Transportation Summary  The Systems Engineering Process (SEP) is an approach that manages the entire life cycle of an ITS System.  The steps of the SEP can be described using the “V” Model.  Cross-cutting activities occur throughout the SEP.  ITS Architectures, ITS Standards, and Transportation Planning are all related to the SEP.  The SEP is used for ITS Project Development to meet Federal requirements.

45. 45 U.S. Department of Transportation References  SE Guidebook for ITS: http://www.fhwa.dot.gov/cadiv/segb http://www.fhwa.dot.gov/cadiv/segb  INCOSE Handbook (2007)  US National ITS Architecture: http://www.iteris.com/itsarch/index.htm http://www.iteris.com/itsarch/index.htm  ITS PCB Standards Training: http://www.pcb.its.dot.gov/stds_training.aspx http://www.pcb.its.dot.gov/stds_training.aspx

46. 46 U.S. Department of Transportation Questions? 1.What are the key benefits of using a SEP? 2.What are the key contributions of the Concept of Operations and the System Requirements? 3.Describe the difference between verification and validation. 4.Describe the importance of configuration management and traceability. 5.Describe the relationship between a regional ITS architecture and the SEP.