ITSIA Second Round of Workshops ITS Israel Architecture

Transcription

1 ITSIA Second Round of Workshops ITS Israel Architecture May 2010 Robert S. Jaffe, Ph.D., CSEP President, Consensus Systems Technologies ( ConSysTec ) Shenorock, New York, USA rsj@consystec.com itsia.mot.gov.il/ 1

2 Systems Engineering (SE) We practice SE to Reduce the Risk of: Cost/Schedule Overage Building the Wrong System ITS Architecture is the first step of SE ConSysTec 2

3 Systems Engineering Project Lifecycle Regional Feasibility Study Architecture(s) / Concept Exploration Operations and Maintenance Changes and Upgrades Retirement/ Replacement Concept of Operations System Requirements High-Level Design Detailed Design System Validation Plan System Verification Plan (System Acceptance) Subsystem Verification Plan (Subsystem Acceptance) System Validation System Verification/ Deployment Subsystem Verification Unit / Device Test Plan Unit / Device Testing Software / Hardware Development Field Installation Document/Approval ConSysTec Time Line Implementation 3

4 Cost of Correcting System Defects Phase that Defect is Created Fix It Here 100x+ Cost to Correct ConOps 1x Requirements 1x Design 1x Construction 1x ConSysTec ConOps Requirements Design Construction O&M Phase that Defect is Corrected (Adapted from McConnel, Steve, Code Complete ) 4

5 ITS Architecture is a Consensus Institutional Architecture (1 of 2) Needs and Services to meet the needs Stakeholders: Their Roles and Responsibilities and Their ITS Elements Information Flows between ITS elements to do services ITS Standards selected to encode the information flows ConSysTec 5

6 ITS Architecture is a Consensus Institutional Architecture (2 of 2) ITS Element Functional Requirements to issue and receive the information flows Agreements required between ITS stakeholders Technology Neutral Must be a Consensus ITS Architecture ConSysTec 6

7 Step by Step Architecture Use in Project Regional ITS Architecture Development Concept of Operations 2 System Requirements 3 1 High-Level Design Detailed Design 4 ConSysTec 7

8 Project Critical Success Factors (reduce to a few bullets) - From a Standish Group Report Project Success Factors Success Points 1. User Involvement Executive Management Support Clear Statement of Requirements Proper Planning Realistic Expectations Smaller Project Milestones 9 7. Competent Staff 8 8. Ownership 6 9. Clear Vision & Objectives Hard-Working, Focused Staff 3 Total 100% 8

9 Contribution of ITS Architecture and Systems Engineering to Project Success Project Success Factors Points Success Potential of Your Project Yes = Add Points Value; No = 0 1. User Involvement 19 ITS Architecture: Involves all stakeholders 2. Executive Management Support 3. Clear Statement of Requirements 16 ITS Architecture: Involves Executive Mgmt. & Policy Makers 15 Systems Engineering: Requirements Mgmt. 4. Proper Planning 11 ITS Architecture & Systems Engineering: Planning throughout Project Life-Cycle 5. Realistic Expectations 0 Project Specific 6. Smaller Project Milestones 0 Project Specific 7. Competent Staff 0 Project Specific 8. Ownership 0 Project Specific 9. Clear Vision & Objectives 0 Project Specific 10. Hard-Working, Focused Staff Total 61% 0 Project Specific 9

10 I-93 Closed at Decatur Blvd. ITS Framework: A Regional Architecture Traffic Travelers Traffic Information Request for Traffic Information ConSysTec Transit Emergency Service Providers 10

11 Framework/Regional/Project ITS Architectures & Standards Other ITS Standards (e.g. SIRI, UTMC) Logical US National ITS Architecture Physical Other National ITS Architectures (e.g. Canadian) Selected ITS Standards Israel ITS Architecture Project Architectures ConSysTec 11

12 National ITS Architecture is a Living Document Continuing evolution of the architecture over 10 years Version 6.0 continues support for ITS technical evolution and deployment User Services 1993 Architecture Published 1996 Phase I & II Development HRI 1997 Ver ADUS Ver MCO Ver Transportation Security Ver Version ConSysTec 12

13 Vehicle to Vehicle Communications Dedicated Short Range Communications Subsystem Diagram Travelers Centers Remote Traveler Support Personal Information Access Traffic Management Information Service Provider Emergency Management Emissions Management Toll Administration Transit Management Commercial Vehicle Administration Fleet and Freight Management Maintenance & Construction Management Archived Data Management Wide Area Wireless (Mobile) Communications Fixed-Point to Fixed-Point Communications Vehicle Roadway Maintenance & Construction Vehicle Commercial Vehicle Transit Vehicle Emergency Vehicle Vehicles Field Security Monitoring Toll Collection Parking Management Commercial Vehicle Check ConSysTec 13

14 ITS Architectures Facilitate Transportation Infrastructure Integration Public Safety ITSIA is a plan for Transportation Infrastructure Integration Rail Roadways Public Transport 14

15 The ITSIA will Support the ITS Project Life Cycle Monitoring & Evaluation Planning Identified Projects Operations & Maintenance Programming/ Budgeting = Implemented Projects ITSIA Use Implementation Funded Projects 15

16 ITS Israel Architecture Components 1. Region scope 2. Stakeholder identification 3. Stakeholder roles & responsibilities 4. Stakeholder agreements 5. Functional requirements 6. Interfaces / Information flows 7. Standards identification 8. Project sequencing 9. Maintenance plan 16

17 Market Packages Architecture Framework spanning all of ITS Transit Vehicle Transit Management Market Packages Pieces of the architecture that provide a particular transportation service. 17

18 Moving Standardized Information between ITS Elements: Architecture Flows Traffic Management signal control status traffic flow signal control data Roadway vehicle probe data request tag data Vehicle Architecture Flows Identify the expected types of information messages that flow between ITS elements Provide a high-level mapping to ITS standards 18

19 Automated Transit Fare Payment Enforcement Transit Management Center Financial Institution Transit Vehicle Point of Sale / Kiosk TM Insert this way. This side up. 19

20 Automated Transit Fare Payment Market Package Enforcement Agency violation notification Financial Institution payment request transaction status Roadway roadway info system data Transit Management fare and payment status bad tag list Transit Vehicle transit fare payment request transit fare payment responses Remote Traveler Support request for payment payment request for payment payment Traveler Card 20

21 ConSysTec 21 Customized Market Packages

22 Architecture Use in Concept of Operations Concept of Operations The architecture provides a good start for a project concept of operations Regional ITS Architecture Concept of Operations * 1. Region description 2. Stakeholder identification 3. Operational concept 4. Functional requirements 5. Interfaces / Information flows 6. Agreements 7. Standards identification 8. Project sequencing 9. Maintenance plan 1. Scope 2. Referenced Documents 3. User-Oriented Operational Description 4. Operational Needs 5. System Overview 6. Operational Environment 7. Support Environment 8. Operational Scenarios * Outline per ANSI/AIAA G System Requirements ConSysTec 22

23 Architecture Use in Concept of Operations Concept of Operations 2 System Requirements Example Maine DMS Project Roles and Responsibilities Architecture Roles and Responsibilities Maine DOT Local Traffic Departments Provides the roadside elements of traffic information dissemination including DMS and HAR Share traffic information with other transportation agencies Project Roles and Responsibilities Maine DOT M&O Maine DOT (Other Areas) City of Portland Develop DMS System Operate DMS System Maintain DMS System Coordinate with partners Support System Development Coordinate diversion/detours with Maine DOT Adapt signal control (future) ConSysTec 23

24 Architecture Use in System Requirements System Requirements 3 High-Level Design 1. Region description 2. Stakeholder identification 3. Operational concept 4. Functional requirements 5. Interfaces/Information flows 6. Agreements 7. Standards identification 8. Project sequencing 9. Maintenance plan Concept of Operations System Requirements High-Level Design Detailed Design ConSysTec 24

25 Architecture Use in System Requirements System Requirements 3 High-Level Design Architecture functional requirements are a starting point Architecture Functional Requirements Inventory Element Functional Area A A.1 Functional Requirement A.2 Functional Requirement A.3 Functional Requirement Functional Area B B.1 Functional Requirement B.2 Functional Requirement B.3 Functional Requirement Project System Requirements Functional Requirements A.1 Functional Requirement A.1.1 Functional Requirement A.1.2 Functional Requirement A Functional Requirement Interface Requirements Performance Requirements Reliability Requirements Maintainability Requirements Development Requirements Additional Specificity and Detail Additional Types of Requirements ConSysTec 25

26 System Requirements Under element, Equipment Package Element ARTIMIS Operations Control Center Functional Area ID Requirement TMC Traffic Information Dissemination 1 The center shall remotely control dynamic messages signs for dissemination of traffic and other information to drivers. DMS Project Requirements The center shall remotely control dynamic message signs Add detailed child requirements to: Activate and display a message Prioritize messages Define a message (pick list, spell check) Blank the sign Schedule messages for display ConSysTec 26

27 Architecture Use in Project Design High-Level Design Detailed Design 4 1. Region description 2. Stakeholder identification 3. Operational concept 4. Functional requirements 5. Interfaces/Information flows 6. Agreements 7. Standards identification 8. Project sequencing 9. Maintenance plan Concept of Operations System Requirements High-Level Design Detailed Design ConSysTec 27

28 Architecture Use in Project Design DMS Project ITS Standards High-Level Design Detailed Design 4 Document ID NTCIP 1101 NTCIP 1102 NTCIP 1103 NTCIP 1201 NTCIP 1203 NTCIP 2101 NTCIP 2102 Standard Title Simple Transportation Management Framework (STMF) Base Standard: Octet Encoding Rules (OER) Simple Transportation Management Protocol (STMP) Global Object Definitions Object Definitions for Dynamic Message Signs Point to Multi-Point Protocol Using RS-232 Subnetwork Profile Subnet Profile for PMPP Over FSK modems NTCIP 2103 Subnet Profile for Point-to-Point Protocol using RS 232 NTCIP 2104 NTCIP 2201 NTCIP 2202 NTCIP 2301 NTCIP 2302 NTCIP 2303 Subnet Profile for Ethernet Transportation Transport Profile Internet (TCP/IP and UDP/IP) Transport Profile Application Profile for Simple Transportation Management Framework (STMF) Application Profile for Trivial File Transfer Protocol Application Profile for File Transfer Protocol (FTP) Select and tailor for project ConSysTec 28

29 Example ITS Architecture Flow Mapping to ITS Standards roadway information system data NTCIP C2F: NTCIP Center-to-Field Standards Group NTCIP 1201: Global Object Definitions NTCIP 1203: Object Definitions for Dynamic Message Signs (DMS) 29

30 System Design The architecture identifies the project interfaces that must be specified. ODOT/KYTC NMDOT ARTIMIS NMDOT Statewide Operations Control TMCenter ODOT/KYTC ARTIMIS DMS Local Computer Sign NTCIP 1203, roadway information system status roadway information system data ICD (NTCIP) ICD Communications Center ICD (NTCIP) Cabinet/Sign Controller ConSysTec 30

31 C2F Interface Specification Profile Requirements List (PRL) 31

32 Summary: Needs and ITS Architecture Benefits Needs related to Planning and Development of ITS Systems 1). Early definition of integration opportunities between ITS systems, particularly where the interfaces cross institutional boundaries. 2). Definition of open standards that can be used to implement key interfaces of ITS projects. 3). Definition of stakeholder's ITS services, ITS elements roles and responsibilities, and high-level functional requirements allocated to stakeholder ITS elements. 4). Identification of cooperative opportunities between different stakeholder projects. Benefits Reduced time to develop projects involving institutional integration. The architecture will enable institutional agreements to be developed in advance of ITS project development. Reduced time to select and agree to interface standards crossing institutional boundaries when ITS projects are developed. Reduced time to perform project preliminary engineering for each ITS service, including accelerating development of a Concept of Operations that stakeholders can agree to quickly Achieve better efficiency for future investments, e.g. avoid redundant surveillance by multiple Traffic Operations Centers (TOCs) that can now share transportation monitoring information. 32