Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
All other engineering disciplines have a graphical method of describing a design; their own language that everyone in the discipline understands.
Electrical schematic, mechanical drawing, building architecture.  All have well-know graphical images of system components that are instantly recognizable.  Anyone from the discipline can view one of these drawings and understand what the designer is trying to embody.
The Connected vehicle world did not have an equivalent graphical language
ITS  has always had the ITS National Architecture tool for people to use to describe ITS projects.  But there was no uniformity or consistency.  It was really just clip art cartoons.
People involved with newer, connected vehicle projects have not use the tool because of its shortcomings – the tool does not describe communication intensive projects.  They tended to use unique graphical images of their projects that are inconsistent from one project to the next.  There is no way to mash them all up to see an overall view of the connected vehicle world.
We found that the new, connected vehicle ITS projects involved much more communication than any previous ITS projects, and that certain aspects of the communication such as Trust are very important. 
Also, connected vehicle applications imply greater integration of service components from independently managed facilities and devices than previous ITS, which tended to be more monolithic.
Also, much more data is now involved, and that that data flows and evolves as part of the system.
Lastly, there are now many more communication media available to accomplish the communications than before.  Some communications could use different media opportunistically.
All of the factors on the previous slide led to realization that the ITS National Architecture tool needs an update.
At the same time, it should also be noted that the ITS National Architecture Tool has some very unique qualities that make it much better for our purposes than the graphical tools used in other disciplines.
ITS National Architecture tool project plans provide three views:
1)One that shows all of the THINGS that make up the system – software, parts in vehicles, equipment on the side of the road, etc.,
2)One that shows all of the PEOPLE who own and manage the things, and their relationships – often different parties with no fixed relationships (constantly changing cast of characters), and
3)One that shows the INFORMATION that flows between the objects as controlled by the relationships between the people.
So we’ve created three views of the architecture: interchangeable parts, common tools
Physical is about the THINGS that interact to provide C-ITS functionality
Interconnect characteristics: Encryption, signing, directionality, initiation of information exchange, broadcast or unicast traffic pattern and development status
Application object characteristics: What it is, what its development status is
Enterprise is about the PEOPLE that make it all work
Communications is about the protocols that enable interaction between physical objects (things)
We’re starting to find that we can use this graphical language as the front-end of automated code generation
All based on the CVRIA, but an evolution of that tool to support conveying more information graphically.
Color: meaning is consistent, and important. 
Application objects define the functionality that is required for each physical object to support one or more Connected Vehicle applications.  The application objects serve as application-oriented containers for the functionality defined in the Functional View.
Nuanced detail added to the lines representing information flows.  In this way, the diagrams provide engineering-level information.
Physical Layer 0:
Identifies Physical Objects at the Project Level
Identifies the existence of information flows that are relevant to the project. Flows are identified in one of three ways:
as a legacy flow, in which case it can be precisely named as an information flow,
as a Peer-To-Peer Data exchange, or
as a Broadcast from one to the other.
Flows may be color coded as to legacy, trusted or confidential
Physical Layer 1 expands on the definitions of the flows and objects
Physical Objects are expanded to include the application objects inside.
Flows are detailed to consider the following attributes:
Directionality of P2P exchanges, indicating the party that initiates the exchange
Status of flow (legacy, new, future)
Type of data in every flow, with a high level notional name
Time and spatial context of data in every flow
Confidentiality and trust carried over from layer 0
All flows from one object to another object that appear on layer 2 are rolled up into one flow here, unless they have characteristics that make their underlying information flow patterns markedly different.
Layer 2 gets into more detail, maintaining all of the characteristics of layer 1, while getting to the information flow level of CVRIA. Multiple information flows between a pair of objects are allowed.
This is an expanded view to show more detail of the information flows.
Situation Data Processing Center interacts with legacy ITS Roadway Equipment. Those legacy flows are specified at a low level because they already exist. We can tell they are legacy because the lines are solid. They are black in color, indicating they are unsecured by any digital certificate mechanism.
Southeast Michigan ITS Roadway Equipment provides signal phase and timing data to Southeast Michigan Roadside Equipment. This flow is unsecured but a new thing, part of the testbed (dashed line).
The Southeast Michigan Local Current Situation Data Warehouse has a new flow to the Situation Data Processing Center. This flow is encrypted and initiated by the warehouse.
This leads us to the communications protocols and media required to facilitate this flow.
If we drill down into the information flow of that one particular information flow . . .
For each information flow, we can develop a communications view diagram that illustrates the stack of protocols that implement the flow.
If 5.9 GHz DSRC is used, the RSE might not be part of the flow on the physical diagram, but does serve as a network access point so it appears here, as it does pass the relevant data.
Security protocols are shown in between the protocol stacks. For a signed, encrypted message, the message is built, encoded, signed, encrypted and then shipped out UDP/IP.
This kind of diagram allows us to trace the flow of data across boundaries of different elements in the system.
The same color-coding scheme carries over to the Enterprise-Level view
All participants in the system have expectations about how the equipment of all parties is operating and about the data being produced. But they have no agreements with each other
Enterprise view diagrams address four phases of the system life cycle
For this project, we have only documented Operations; the CVRIA talks about all phases
We know that the components and participants change over the life cycle . . .
. . . so the Enterprise viewpoint allows us to keep track of all the interconnections at any given point in time.
Enterprise View, operations phase, including support applications and basic situation data distribution for Southeast Michigan 2014.
Assumes two types of vehicles, two data warehouses and one TMC. Additional data users would have similar relationships to the support
and data warehouse operators as the Arterial Traffic Manager has. Additional vehicles would have similar relationships as the vehicle shown here, though if the driver is not the same as the vehicle owner additional relationships are likely required.
Agreements and Expectations:
Agreements are contracts that detail the relationship between two parties,
Expectations are understandings about the relationship that is based on just that; a mutual understanding about what should happen.  The understanding can be tested because both parties will sign their contributions with cryptographic credentials from a common, trusted source.
This is a zoom-in on one section, to show details . . .
Various relationships between the Test Bed Operator and Arterial Traffic Manager (ATM), and between the Test Bed Operator and 3rd Party Application Provider (3P)
The Test Bed operator owns and operates the security system (not shown on this snip); in order to acquire the credentials necessary to operate in the environment, the ATM and 3P must have an agreement with the Test Bed Operator; the Security Information Exchange Agreement
The Test Bed operator owns and operates the local current situation data warehouse(not shown on this snip); in order to receive data from that warehouse, the ATM and 3P must have a usage agreement that indicates as such.
Expectation of Information Exchange is all about provision of SPaT data from the RSE, and also interaction with the ORDS, which is expected to exist and provide service without any formal agreement.
[Showing example of the CVRIA Mini-tool]
This is the beginning of a computer-aided engineering tool to support CV systems development
People can get involved in the Southeast Michigan 2014 project two ways:
Be part of an on-going DOT activity, or
Be part of the Affiliation of Test Beds.
You can download an early version of the tool – use it to design schematics of your projects, to have a common graphical language and way of documenting details
Question about color coding: what about color blind people?
Answer: we expect people to use descriptive names for the objects in the boxes.  Also in future we expect 508 compliance, etc.