|
1
|
|
|
2
|
- Opening Comments, Program Overview
- Core System Background, Overview
- ConOps Discussion
- System Description
- Core System Next Steps
|
|
3
|
- Welcome, Program Overview
|
|
4
|
- Who we are, how we got here
- Purpose for today
- Present the Core System ConOps
- Open discussion, questions/comments captured
- Preview architecture development activities
- Breaks: 10:15-10:30, 2:15-2:30
- Lunch: 12:00 – 1:15
|
|
5
|
|
|
6
|
|
|
7
|
- Background / Overview of the overall environment / Core System and its
components
|
|
8
|
- Safety
- 33,963 deaths in ‘09
- 5,800,000 crashes/year
- Leading cause of death for ages 4-34
- Mobility
- 4.2 billion hours of travel delay
- $78 billion cost of urban congestion
- Environment
- 2.9 billion gallons of wasted fuel
- Emissions
|
|
9
|
- Drivers, Passengers, System Operators
- Using wireless communications technologies and applications
- Realize
- Safety, Mobility, Environmental benefits
|
|
10
|
|
|
11
|
- Since VII, additional communications media available
- Expanding of both mobile platforms (all vehicle types, plus pedestrians
and other road users) and potential users of data, providers of data
(not just traditional transportation players)
- Applications development, include data capture and usage is decoupled
from a single large system
|
|
12
|
- Provides common services and interfaces
- Provide trusted environment for the applications and users
- Support diversity
- applications, communications media, deployment models
- Plan for the future
- Future technologies, extensible architecture
|
|
13
|
- Enable data transfers between system users
- 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
|
|
14
|
- What the Core System Does NOT do…
- Store data for long periods of time
- Host applications
- Sit in a single location
- Require any particular comm or hardware technologies (other than what
will be needed to support the requirements)
|
|
15
|
|
|
16
|
|
|
17
|
- Give me the data – current traffic, all roads, all the time
- Standardize it
- Support multiple modes – include Cyclists, Pedestrians, other vulnerable
users
- Set driver’s expectations: inform them when safety or mobility services
are available
- Support targeted broadcasts to sets of vehicles by location, type,
individual
- Support multiple uses of data sets via standardized interfaces, services
- Support roaming for users devices
- Provide authentication, ensuring users that messages are from legitimate
sources
|
|
18
|
|
|
19
|
- Characterize the Current System
- Identify users’ Needs
- Define Concepts of the Proposed System
- Operational Scenarios of the Proposed System
- Summary of Impacts, Analysis
|
|
20
|
- Initial Draft delivered October 2010
- Reviewed by DOT, support staff, VIIC/CAMP, Testbed team
- Needs from perspective of application users/stakeholders,
- Determined that Core System ConOps should focus on underlying needs
across the board of all system users
- Revision A delivered January 2011
- Focus on Core System and its System Users and their common needs:
security, network services, data distribution, system management
- Consider Applications and Communications separately from the Core
System
- Rev B – April 2011 (Rev C corrected formatting)
- Incorporated walkthrough comments; confirmed Needs and system elements
|
|
21
|
- Current System Discussion
- Needs – Justification for Changes to Current System
- Concepts of the Proposed System
- Operational Scenarios of the Proposed System
- Summary of Impacts, Analysis
- References
|
|
22
|
|
|
23
|
- Transportation Users, e.g., private vehicle drivers, public safety
vehicle operators, commercial vehicle operators, passengers, cyclists
and pedestrians
- Transportation Operators, e.g. traffic managers, transit managers, fleet
managers, toll operators, road maintenance and construction
|
|
24
|
- Public Safety, e.g. incident and emergency management, including fire,
police and medical support
- Information Service Providers, including traffic, weather and mobility
applications
- Environmental Managers, including emissions and air quality monitors
|
|
25
|
- Manufacturers/Developers:
- Vehicles, onboard devices, field equipment, software
- Communications Providers, including cellular network operators
- Federal regulatory and research agencies
|
|
26
|
|
|
27
|
|
|
28
|
- Flexibility
- Extensibility
- Scalability
- Maintainability
- Deployability
- Reliability
|
|
29
|
|
|
30
|
|
|
31
|
|
|
32
|
|
|
33
|
|
|
34
|
- 2 Types of Needs Addressed:
- User needs – capability required for that user to accomplish their goal
- System needs – capability required in order to meet the operational
goals
- In a nutshell:
- Provide trust/security
- Enable data exchanges
- Take care of itself
- Work with other cores
|
|
35
|
- Data protection
- Facilitate secure exchange of data
- Facilitate trust
- With and between System Users
- Revoke trust credentials when necessary
- Authorization
- Manage who can do what
- Verify
- Identify misbehavior and allow System Users to provide misbehavior
input
|
|
36
|
- Time
- Components of Core System use standard basis for time, synchronization
- GROUP DISCUSSION
- Should Core provide that Time information/sync data to its System
Users?
|
|
37
|
- Facilitate the provision of data
- Match data providers with data consumers
- Data redistribution (publish-subscribe, aggregation, anonymization,
etc.)
- Facilitate situational-relevant distribution
- GROUP DISCUSSION
- Should Core advertise applications available to its System Users?
|
|
38
|
- Network Services
- support users accessing Core System over variety of communications
mechanisms
- Take care of itself
- Service Status
- Integrity Protection
- System Availability
- Performance Monitoring
|
|
39
|
- Coordinate activities with other Core Systems
- Support multiple, independent deployments
- While providing Interoperable services across Cores
- And coordinating activities together to deliver information
consistently
|
|
40
|
- VII Privacy Policies Framework still applies
- IEEE 1609.x family used for DSRC
- X.509 based certificates except for DSRC-specific apps
- SAE J2735 basis for mobile user messages
- Other open standards may be needed for Core System interfaces
- Comm based on IP v6
|
|
41
|
- Comm will be provided by System Users
- Data (probe, basic safety) provided anonymously by mobile users
- Some vehicle based safety applications
may be mandatory (beyond scope of this effort)
- Other mobility applications will be opt-in
- Deployment of Cores may be evolutionary, regional
|
|
42
|
- The System – its subsystems and its interfaces
|
|
43
|
- What is it?
- Set of services, enabling higher-level applications
- Just what can I do with this thing?
- Who Am I?
- System Users
- Core System Personnel
- Administrators, Operators, Maintainers, Developers, Deployers
|
|
44
|
|
|
45
|
- Heterogeneous community of systems, agencies, locations
- (Don’t think control center) – not a physical plant, it’s a collection
of services
- Different Deployment Considerations
- Standalone
- Collocated
- Distributed
|
|
46
|
|
|
47
|
|
|
48
|
|
|
49
|
- Differentiated by location
- Center users are at fixed-point, back-office or operational centers
- Field users are located in proximity to the transportation environment;
i.e., on the roadside
- Mobile users are in the transportation environment, and mobile (duh!)
- All use the Core System in the same basic ways
- Experience may be limited by the communications they have
|
|
50
|
- What do they need to do with the Core System?
- Get certificates
- Receive certificate revocation lists
- Why?
- To enable other people to trust you
- To know whether to trust others
- To send and receive encrypted messages
- To be able to run applications
- Everything – safety, mobility, environmental
- Especially: V2V safety
|
|
51
|
- What data can the System User get from the Core System?
- Whatever other System Users are providing
- Focused on Mobile ßŕ Center
- How does it work?
- Data consumers subscribe to receive data, specifying types that they
want
- Data providers register to provide data, specifying types that they can
provide
- Core provides forwarding, aggregation and anonymity
- Core may enable direct provider-to-consumer linkage
|
|
52
|
- Does it do anything else?
- Network services
- Provides support services necessary to enable communications for users
of DSRC networks.
- Provides situational-relevant dist
- User Permissions: allows a user to query whether a given message was
sent by a user allowed to send that message.
|
|
53
|
- But wait, there’s more!
- Service Monitor:
- Tells you what Core services are available (data distribution, network
services etc.)
- Tells you what applications are registered in the area, and where they
operate.
- Misbehavior Identification
- Allows you to tell the Core who you think is misbehaving
- Analyzes data sent by users, identifies bad actors, revokes their
permissions and certificates if appropriate
|
|
54
|
- Subsystems to address the needs, provide the Core Services
- Core2Core
- Data Distribution
- Misbehavior Identification
- Network Services
- Service Monitor
- User Permissions
- User Security
- Time
|
|
55
|
- If a Core provides a service, must it provide that service regardless of
end-user communications capabilities?
- Yes:
- Makes it simple to determine which Core is responsible for each
services,
- But increases the complexity Core-side for providing services over
varied communications media with varied performance characteristics.
- May want to allow for Cores that could be dedicated to certain types of
media (i.e., the 4G Core, the DSRC Core, etc.)
|
|
56
|
- Could multiple Cores share provision of the same service in a given
area, even over the same communications media type?
- Yes.
- There would have to be one default provider for overlap areas, but
there could be multiple providers.
- As long as Mobile/Center/Field users could change their Core service
provider, this could work.
- Also, there could be multiple DSRC infrastructure providers in the
same area.
|
|
57
|
- Can a user make use of the same service from multiple Cores?
- What services need to be coordinated between Cores?
- Data distribution
- Misbehavior Identification
- Network Services
- User Permissions
- User Security
|
|
58
|
- How System Users will interact with the Core
|
|
59
|
|
|
60
|
|
|
61
|
|
|
62
|
|
|
63
|
|
|
64
|
|
|
65
|
|
|
66
|
- The provision of communications between two devices is not inside the
Core.
- RSE are outside the Core
- As are Blutooth, WiFi, Cell towers, etc.
|
|
67
|
- Deployment and maintenance: this makes the Core System a set of
software, that can be deployed anywhere and operate over any area,
independent of the deployment of communications.
- Flexibility: by decoupling communications architecture from core
services, intra-core policies are separated from access mechanisms. This enables a variety of Core2Core
relationships, and offers users more flexibility.
|
|
68
|
- Direct Connect: device is capable of directly addressing the Core
System. May include RSE
& other field devices,
centers, and mobile devices connecting through wide-area wireless.
|
|
69
|
- Indirect Connect: device requires an intermediary in order to exchange
data with the Core. Indirect
connect includes mobile devices connecting through DSRC, and may include
RSE and other field equipment and any other mechanisms.
|
|
70
|
- The deployment and maintenance of field infrastructure is separated from
the provision of enabling services.
- The deployment and maintenance of communications networks is separated
from the provision of enabling services.
- Communications to support the larger connected vehicle environment can
be customized for each deployment;
- Based on the needs of the deploying stakeholders
|
|
71
|
- Collecting Feedback, Proceeding
|
|
72
|
|
|
73
|
|
|
74
|
- Architecture: The fundamental organization of a system, embodied in its
components, their relationships to each other and the environment, and
the principles governing its design and evolution. (IEEE
1471)
- Viewpoint: a framework of rules for developing architecture views based
on a related set of concerns
- View: a representation of the system from the perspective of a set of
concerns
|
|
75
|
|
|
76
|
- Stakeholders and their Concerns
- Viewpoint Specifications
- Views defined in accordance with those Viewpoints, each of which
addresses specific stakeholder concerns
|
|
77
|
|
|
78
|
- Enterprise:
- Organizational entities and their relationships. Focuses on scope and
policy.
- Functional:
- System as a collection of abstract objects that interact at interfaces.
- Connectivity:
- System as a set of components that interact across links.
- Communications:
- Mechanisms required to communicate between system components.
- Information:
- Kinds of information handled by the system.
|
|
79
|
|
|
80
|
|
|
81
|
- Provides mechanism to explore alternative views
- Includes traceability between views (across viewpoints)
- As well as traceability to Requirements
|
|
82
|
- Feedback from today – please provide to DOT
- System Requirements Specification and draft System Architecture Document
- Will include alternative architectures to be reviewed and discussed
- Next public workshop: June 28-30, 2011 in Washington, DC
|
|
83
|
|
Notes
