290 likes | 391 Views
STARNET Implementation. Warren Tighe Siemens ITS January 5, 2006. Presentation Outline. The goals of STARNET Similar efforts around the country Implementation plan and process The role of Siemens ITS Scope of work Time schedule. The Goals of STARNET.
E N D
STARNET Implementation Warren Tighe Siemens ITS January 5, 2006
Presentation Outline • The goals of STARNET • Similar efforts around the country • Implementation plan and process • The role of Siemens ITS • Scope of work • Time schedule
The Goals of STARNET • STARNET = Sacramento Transportation Area Network • Connect the region’s real-time transportation management systems • Allow sharing or real-time data between systems and between users • Allow sharing of live video • Provide real-time information to the public via 511 and other outlets
Why Build STARNET? • Make travel easier and safer • Gather and disseminate more and better real-time travel information • Better travel decisions – time, mode, route • Provide transportation system managers with more and better real-time information • Including information from other agencies • Better operational decisions and actions • Allow shared use of field devices when appropriate • Better use of resources and better operation
Transp Managers See Whole Picture Without STARNET With STARNET
Some STARNET Components Roseville CCTV System Elk Grove Traffic Signal System Sac County Traffic Signal System Roseville Traffic Signal System Sac County CCTV System Sacramento CCTV System RT LRT Ops Management System Communications Network Sacramento Traffic Signal System RT Bus Ops Management System SACOG Travel Info System RT CCTV System Sac Bee Travel Info System CHP Incident Tracking System (CAD) Caltrans Freeway Detector System C/T Freeway Dynamic Signs System Caltrans CCTV System
Examples of More Components • SACOG travel data repository • Sac County dynamic signs system • Citrus Heights traffic signal system • Yolo County Transit management system • Caltrans weather information system • Sheriff & police incident tracking systems • Union Pacific Railroad train tracking system • Etc.
Travel Information • STARNET can be a boon for 511 • Gather more real-time information from more sources • Travel information servers are just more nodes on the network Transit Systems Communications Network Caltrans Systems Travel Info Systems County Systems City Systems
Examples Elsewhere • I-95 corridor • Milwaukee-Chicago-Gary corridor • New York statewide (IEN) • Texas statewide • New York City area (TRANSCOM) • San Francisco Bay area • Los Angeles County (IEN and RITTS) • Etc. • Many similar systems now being implemented
The Nature of STARNET • A system of systems • A network of systems • Peer-to-peer communications • Owned and used by multiple agencies • Open to all agencies – may come and go • Use to get data and/or send data • Agencies participate only as desired • Dependent on no one agency or vendor • Just like the Internet
Interface to Agency Systems • Build translators as needed to accommodate existing systems. • Develop new systems where needed. • Future systems should come with standard interface ready to plug in. Existing System with Translator Communications Network Translator New System with Standard Interface
What Do We Implement First? • Can’t afford to do everything at once • Prioritize • Plan a staged implementation • Make it flexible and expandable (scalable) • Allow for on-going change • Identify on-going funding
What Process is Needed? • Must design it in order to build it • Must have requirements in order to design it • Must have user needs in order to identify requirements • Must have a concept of operations in order to understand and document user needs
The Process Concept of Operations User Needs Requirements Design Build & Test
Systems Eng Management Plan Operation & Maintenance Operation and Maintenance Plan System Validation Concept of Operations Validation Plan System Verification & Deployment System Requirements Acceptance Testing Plan High-Level Design & Subsystem Requirements Integrator’s Testing Plan Subsystem Verification Detailed Design Unit Testing Software Coding Hardware Fabrication Part of Systems Engineering
SEMP Con Ops Validate System Test & Deploy Sys Req. Subsys Test High- Level Design Unit Test Design Build The Process Will Repeat Plan Operate (use) Cutover Plan SEMP Operate Con Ops Validate System Test & Deploy Sys Req. Subsys Test High- Level Design Unit Test Design Each maintenance change, enhancement, upgrade, or replacement Build
The Role of Siemens • Siemens ITS contracted by SACOG to provide Systems Engineering Assistance during STARNET implementation. • We will, effectively, serve as specialty staff to the stakeholders. • We have done this for several other center-to-center networks around the country. • We will strive to fully understand the stakeholder needs and guide STARNET implementation accordingly. • A separate firm will be hired to perform system integration. Siemens will help write the RFP and oversee that effort.
Siemens Work Plan • Task 1 – Systems Engineering Management Plan • Task 2 – Concept of Operations • Task 3 – Requirements & Testing Plan • Task 4 – High Level Design + Hire System Integrator • Task 5 – Oversee System Integration
Systems Engineering Management Plan • Work break down structure for overall STARNET implementation (more than just the Siemens work) • Time schedule and interdependencies • Control gates – where formal approval is needed to continue • Resources needed for each step and where they will come from • Specific management plans – see next slide
Specific Management Plans • Stakeholders Cooperation Plan • System Integration Services Procurement Plan • System Verification (testing) Plan • Documentation Plan • Configuration Management Plan • Operations and Maintenance Plan • Data Management Plan • Interface Control Plan
Concept of Operations • Goals of STARNET, and list of stakeholders • Use of STARNET • Who will use it? • How will they use it? • Where, when, why, etc.? • Describe operational scenarios • Constraints (e.g., funding) • Opportunities (e.g., low hanging fruit) • Validation metrics – how do we know if we succeeded?
User Needs • Extract from Concept of Operations • A list of needs • Written in plain language that stakeholders can easily understand and check • Check that all are justified by the Concept of Operations • Check that none are missed
System Requirements • Derive from User Needs • A list of technical requirements • Written in concise, short, technical, unambiguous statements – precise and quantitative • Basis for system integration contract, design, and acceptance testing • Intended for technical specialists • Check that all User Needs are addressed, and that all Requirements are justified
High Level Design • General concepts and architecture • A guide for prospective system integrators • Will not limit creativity and opportunities available from prospective system integrators • Use for cost estimating and feasibility checks
Stakeholder Involvement • BIG role up front: • Concept of Operations • User Needs • Specialty management plans • RFP for system integrator • Less involved during detailed design and build stage – mainly system integrator • Increasing role as parts ready for review and testing, then training and documentation • Fully engaged again when using the system
Systems Eng Management Plan Operation & Maintenance Operation and Maintenance Plan System Validation Concept of Operations Validation Plan System Verification & Deployment System Requirements Acceptance Testing Plan High-Level Design & Subsystem Requirements Integrator’s Testing Plan Subsystem Verification Detailed Design Unit Testing Software Coding Hardware Fabrication Like Tule Fog for a While
Next Steps • Review draft documents from Siemens • System Engineering Management Plan • Strawman Concept of Operations • Attend one-day workshop on Concept of Operations • Review and discuss strawman Con Ops • Brainstorm improvements to concept of operations • Agree on refined Concept of Operations and User Needs
Schedule of Stakeholder Activities Feb 06 Mar • Concept of Operations workshop in latter half of February – includes User Needs. • Review various specialty management plans in latter half of March. • Review System Requirements and Verification (testing) Plan in late May and in June. • Go on vacation in July. • Review high level design and other documents in August. • Review RFP for system integrator in September. • Review proposals, and interview firms, in December. • System Integrator on board by March 07. Apr May Jun Jul Aug Sep Oct Nov Dec Mar 07