|
1
|
- September 20-22, 2011
- San Jose, CA
- Day 3
- Systems Engineering Team
- connected vehicle Core System
Architecture/Requirements
- Workshop #2
|
|
2
|
|
|
3
|
|
|
4
|
- Enable data transfers between System Users
- Are in a secure, trusted environment
- Enabling trust between parties that have no direct relationship
- Enabling secure data exchange between parties that have no direct
relationship
- Enabling the exchange of data between parties that have data and
parties that want data
|
|
5
|
|
|
6
|
|
|
7
|
- Views that will describe the layered communications protocols
|
|
8
|
- Layered communications protocols between nodes
- Links are traceable to interface requirements
|
|
9
|
- Mobile DSRC Device and Core
- Mobile Wide-Area Wireless User and Core
- Fixed Point Center/Field User and Core, Core2Core
- Core Routing
|
|
10
|
- Description:
- 1st of 2 views showing how Mobile Users can communicate with
the Core
- Shows the intermediary steps to go from Mobile to Core
- Based on 5.9 GHz DSRC using IEEE 1609.x, 802.11p standards
|
|
11
|
|
|
12
|
|
|
13
|
|
|
14
|
|
|
15
|
|
|
16
|
- Description:
- 2nd of 2 views showing how Mobile Users can communicate with
the Core
- Shows the intermediary steps to go from Mobile to Core
- Based on WiFi, cellular, other wireless communications
|
|
17
|
|
|
18
|
|
|
19
|
|
|
20
|
|
|
21
|
- Description:
- Shows how non-mobile systems (Field, Center, External Support Systems,
and other Cores) communicate with the Core
- Wired connections through the Internet or private networks
- May use wireless (see 4.4.2)
- Uses IP protocols
|
|
22
|
|
|
23
|
|
|
24
|
|
|
25
|
- Description:
- Shows the communications involved when the Core is used as a router
when a private network is used to connect mobile, field, or center
systems
- Fixed devices connected to the Core by a private network can use the
Core Access Node to provide connectivity between them
- Could also provide connectivity for mobile users to a Center user
|
|
26
|
|
|
27
|
|
|
28
|
|
|
29
|
|
|
30
|
|
|
31
|
- Views that will describe the data object structures and relationships
|
|
32
|
- Defines the Data objects: structure, relationships, metadata, and
constraints
- Related to interface requirements, referenced by the functional requirements
|
|
33
|
- Top Level External Objects
- Top Level Internal Objects
|
|
34
|
- Description:
- Objects that are exchanged, sent, and received over the Core Systems
external interfaces
- Includes objects between Cores
- Organized by the originating or terminating subsystem
- External interfaces are candidates for standardization
|
|
35
|
|
|
36
|
|
|
37
|
|
|
38
|
- Description:
- Objects that are exchanged, accepted, and sent between subsystems over
the Core Systems internal interfaces
- Organized by the originating or terminating subsystem
|
|
39
|
|
|
40
|
|
|
41
|
|
|
42
|
- How will the Core be rolled-out
|
|
43
|
- Recall from Day 1s background of the Core System
- Core System Needed
- Support diverse implementations
- Extensible, scalable over time
- Support Diverse deployments
- Standalone
- Collocated
- Distributed
|
|
44
|
- Core System Architecture supports those goals:
- Enterprise Objects like Core Certification Authority
- Interfaces like Core2Core
- Ability to vary how software is assigned to nodes
|
|
45
|
- Deployment Considerations as multiple Cores are developed and fielded
|
|
46
|
- Core #1 provides all services for the area. Some areas provide DSRC communications
to Core, resulting in different service delivery profiles.
|
|
47
|
- Core #2 provides all services for the area it covers, all by nG
cellular.
- Core #1 provides all services for the area it covers, some by nG, some
by DSRC.
- Overlap requires agreement, and Core #2 provides services in the overlap
areas here.
|
|
48
|
- Core #2 provides all services for the area it covers, all by nG, except
for the shared area.
- Core #1 provides all services for the area it covers, some by nG, some
by DSRC.
- Overlap requires agreement; Core #1 and Core #2 both provide
services. Each service provided
by only one Core, except for DSRC users that can get all services from
Core #1.
|
|
49
|
- Core #2 provides all services for the area it covers, all by nG, except
for the shared area.
- Core #1 provides all services for the area it covers, some by nG, some
by DSRC.
- Overlap requires agreement; Core #1 and Core #2 both provide
services. Overlap area defaults
to Core #2, except for DSRC users that go to Core #1. Users can override and access Core #1
with 3G if they wish
|
|
50
|
- 1st Steps (take care of the higher risk items)
- Setup the Core Certification Authority to establish:
- Governance policies
- Certification standards and procedures
- Security credentials (root CA)
- Establish the External Support Systems (the CAs and RAs)
|
|
51
|
- Incorporate Lessons from Test Bed, Safety/Certification Pilots
- Work with Standards organizations to incorporate Core System interfaces
into industry standards
- Begin to work with Deployers to establish operating agreements
- What else?
|
|
52
|
- Who is likely to deploy a Core System?
- States
- Locals
- 3rd Party Data Warehouse Providers
- System Integrator
- Auto Industry
- May affect how relationships are defined by the Core Certification
Authority
|
|
53
|
|
|
54
|
- What may happen to prevent the Core System from succeeding and to some
extent, affect the overall connected vehicle environment
- Types of Risks
- Technically Core System is straightforward, using current
technologies
- Institutional Issues always take longer
- Programmatic cost/schedule
- Levels: individual Core, collectively
|
|
55
|
- Timely Deployment
- Relationships between Core Systems and external Enterprises
- Role and Makeup of the Core Certification Authority
- External Support System (ESS) for Security
- Operations and Maintenance of the Security External Support System (ESS)
- More for the connected vehicle environment
- Security Management
- Data Provisioning/Ownership
|
|
56
|
- For Core System and related activities
|
|
57
|
|
|
58
|
- System Engineering Team will finalize
- ConOps
- Requirements
- Architecture
- Risk
- Standards Recommendations
- DOT leading other activities where Core System
- Contact Walt Fehr 202-366-0278, walt.fehr@dot.gov
|
|
59
|
- Thank you all for your Time
|