Design Gaps 2.1.Connected Vehicle System Architecture

2.1.1.System Architecture Description and Requirements

While a variety of system descriptions have been developed, there is currently no fully-consistent set of documents describing the entire connected vehicle system architecture, and there are no corresponding requirements for all elements of the system as it might be deployed. As a result, a practitioner seeking to implement the system would not have a complete and consistent set of specifications and functional descriptions upon which to implement the system.

For example, the core system architecture documentation identifies a variety of functional elements that are part of the connected vehicle system, but are not within the system boundary of the core system. As such these are not treated in the Core System Concept of Operations, and are not addressed from a requirements perspective in the Core System requirements documentation or architectural description. The Core System documentation thus is not by itself sufficient to implement the connected vehicle system.

The Connected Vehicle Reference Implementation Architecture (CVRIA) project appears to be developing a broader architectural description (encompassing elements outside the Core System), but it is not clear that this effort is aimed at generating a complete suite of system requirements and operational concept descriptions, but rather is aimed at identifying interfaces and required standards for interfaces.

The National ITS Architecture appears to be a very high level description into which the connected vehicle system may fit, but it does not appear to address the level of detail required to, for example, assure application interoperability across different implementations.

There have also been a variety of efforts aimed at developing applications-related concepts of operations, but these are not part of any overall systems engineering process, and it is unclear how they relate to the overall unified system. For example, they may or may not include the same functional components and interfaces as the other systems documents.

In general, all of these documents have been developed at different times by different organizations for different purposes, and thus they do not necessarily provide a complete resource for system implementation

Recommendation: Compile a complete set of end-to-end system design documents with concepts of operations for all safety and mobility applications and security management, together with component requirements. These may draw from existing documentation and work done to date, and they may require additional systems engineering work to develop. The result should be a unified system description that clearly sets forth the operations of the system for the primary functional tasks they are to perform, and lays out requirements that will assure interoperability across all implementations of hardware and software.

2.1.2.System Boundary

Many of the existing system descriptions include the concepts of mobile, field and center elements. However, the distinction between which parts of these elements are within the system boundary (and thus subject to system requirements), and which elements are outside this boundary (and thus not addressed by system requirements) is not explicitly clear. For example the “field” elements may include roadside DSRC units and associated application processors, but there are also field elements (such as signal controllers, access gates, etc.) that are clearly not subject to connected vehicle requirements. The currently available documentation for the Core System and the CVRIA do not clearly specify these boundaries, and thus there is significant confusion about the interfaces between the connected vehicle system and the existing infrastructure.

2.1.3.Non Extensible Architecture

Gap : Architecture and Supporting Messaging Standards Are Inflexible and May Suffer From Early Obsolescence

Many aspects of the connected vehicle architecture are based on application-specific designs. For example, most of the SAE J2735 messages are oriented toward supporting specific applications. This means that as new applications are conceived these standards will need to be revised to provide new messages to support them. This issue is also exhibited in the IEEE 1609 WAVE standards, which are intended to support delivery of messages to applications based on fixed identifiers that are generally specific to particular applications and in some cases particular organizations. To support possible future growth, the standard has set aside a space of 4 billion possible “provider service identifiers.” In addition, most connected vehicle development activities are organized around applications to such an extent that in many cases the architecture is refined specifically for these applications. As an example, the current anonymous security design is set up to support certificates for anonymous Basic Safety Messages. As it is currently conceived, the addition of any other applications requiring anonymous certificates will require extending the number of certificates and the supporting management and delivery operations, and these operations are already seen as barely able to handle the currently imagined system scale. If, for example ten applications require anonymous certificates, then the security apparatus and corresponding communications will need to be an order of magnitude larger. Essentially, as currently designed, the system can only support the anonymous BSM and various other V2I applications.

In contrast, the Internet, to which the Connected Vehicle system is often likened, is very generalized, and architected in a way that insulates it from changes in technology and changes in applications. It has withstood massive changes in both and has simply grown to support them. It is likely that under the current application specific and non-generalized architecture and approach, the Connected Vehicle system will be in a perpetual state of technical obsolescence, and many potential applications that might otherwise add enough incremental value to make the equipment and operational costs worthwhile may move to other more easily adaptable media such as the internet and the cellular data system.

Recommendation: Examine the connected vehicle architecture (as much as it is defined - See Gap 1), and identify ways in which it can be made more technology neutral and more application independent. Perform trade studies and analyses to determine if, for example, conventional flexible internet related protocols (e.g., XML) can be supported given the available bandwidth. Seek ways to minimize system dependencies on specific technologies and applications/uses.

2.1.4.Relationship between RSE and Applications

Gap : Inconsistent Understanding of Range of Applications for a Single RSE

Because of the lack of any unified architectural description, there is a significant diversity of opinion about the relationship between an RSE and the application(s) it may support. At one extreme is the view that each RSE must support only a single application. If this is the case, then the RSE will only broadcast the messages associated with that specific application. At the other extreme, an RSE is seen as a terminal that may host a variety of local applications, and may be connected to a variety of remote center elements (e.g., traffic management centers) for which it forwards messages. In this case, the range of applications that the RSE may serve is unbounded. There is no fundamental architectural reason that the unbounded case cannot be supported, but there are practical limitations on the scope of applications on any given RSE.

The deployment impact of this divergence of views is significant. If each RSE is expected to support only one application, then the number of RSEs that must be deployed may be enormous, and the problem of RSE-to-RSE interference will need to be addressed. On the other hand, if each RSE can serve an unbounded set of applications, then managing the RSE processing and radio resources will become increasingly important, and choosing geographic locations that are compatible with all of the RSE applications may be problematic.

Recommendation: Develop a description of the various operational configurations for RSEs that are allowed under the standards. For example:

• 
  RSE broadcasting messages for a single stand-alone local application
  
• 
  RSE broadcasting messages for a multiple local applications
  
• 
  RSE broadcasting messages for a single locally-connected field system such as a traffic signal controller
  
• 
  RSE receiving and immediately forwarding/broadcasting messages from a single center facility
  
• 
  RSE receiving and immediately forwarding/broadcasting messages from multiple center facilities
  
• 
  RSE receiving and storing messages from one or more center facilities and then broadcasting them according to a provided schedule
  
• 
  RSE aggregating data received from passing vehicles and periodically forwarding aggregated or bundled data to one or more repository or distribution facilities (e.g., a Core System distribution function)
  
• 
  RSE Providing IP backhaul/routing services to OBEs in the radio footprint (e.g., for remote services or for security management operations)
  

This description should include a discussion of the policies and technical considerations associated with supporting these various uses of RSEs.

See Related RSE Siting and RSE Location/Latency gaps.

2.1.5.Relationship between RSE Location, Applications and Latency

Gap : Lack of Consensus on Relationship between RSE Location, RSE Applications and Latency Requirements

There is a significant diversity of opinion about the relationship between the RSE location, the applications the RSE may support, and the latency that the applications can tolerate. One view is that the RSE should always be physically associated with the location that the application relates to. For example, a curve speed warning application must be located proximate to the curve. In some applications this view is further supported by concerns about message latency. For example, an RSE supporting SPaT messages must be located at the intersection and the messages must be sent with low latency to vehicles about to encounter the signalized intersection.

In general, these views and concerns are a result of not having a unified system definition where the system architecture is related directly to the applications through a ConOps document that clearly illustrates the steps each architectural element takes to carry out a specific application (See Gap1). An alternative view is that messages can be sent from any RSE that the host vehicle passes prior to encountering the area to which the hazard applies. In that approach the message would include an activation zone and it would lie dormant in the OBE until the OBE entered the geographic activation zone or the message expired (this is how roadway alerts were implemented in the Michigan Proof of Concept system).

In the first approach all messages are acted upon as soon as they are received. This is a valid approach, and it is attractive because it requires no coordination between the message provider and the OBE application developer (i.e., nothing other than a message format standard), but it is nearly impossible to implement since it requires that an RSE be placed at every hazard. Since the hazards are not known in advance it limits the scope of the connected vehicle system to only cover hazards at locations where an RSE is or can be located.

In the second approach, the RSEs may be located at strategic points where they can seed the passing vehicles with messages that may or may not be activated down the road. This is attractive because it substantially limits the number of RSEs, but it assumes coordination and standardization of the operational aspects of the messages and the user applications beyond simple message formatting rules.

Recommendation: See Gaps 1 and 3.

Directory: documents
documents -> Concept stage
documents -> Concept stage
documents -> The great global switch-off
documents -> Nonprofit grant application
documents -> The Truth about the Rwandan Genocide
documents -> Annual InStructional unit plan
documents -> Chaos equipment included

Download 157.83 Kb.

Share with your friends: