Architecture & Standards Use Details

The accompanying figure zooms in on ARC-IT artifacts that are accessed by RAD-IT to support regional ITS architecture development, by SET-IT to support project development/systems engineering, and the communications view artifacts accessed by the Standards Map.

Architecture and Standard Use Details

As shown, RAD-IT uses service packages as a primary entry point that allows the regional architect to select the ITS services of interest and then gather all of the relevant ARC-IT artifacts for those ITS services. The regional architect uses RAD-IT to develop a regional architecture customized to his region. This architecture focuses on:

• Stakeholders, their roles within the architecture with respect to services offered, which address concerns related to responsibility and delivery of services to end users.


• Services offered in terms of service package


• Elements that exist or will exist in the region - these are instantiations of physical objecs from ARC-IT.


• Information exchanges between elements - these are instantiations of information flow from ARC-IT.


• Stakeholder roles and responsibilities - these usually concern the delivery of services or the exchange of information.

RAD-IT also provides the user with the ability to define projects within the region. These are subsets of the region that are "planned" or "future" and are partitioned into projects. A project will include all of the same material as the regional architecture, but only the portion that is applicable to the specific project; thus its scope is considerably smaller.

The project architect can take project specific information from RAD-IT and use it as a starting point in SET-IT to support the systems engineering process used in project development. As shown in the diagram, the starting point for SET-IT use is also Service Packages, which can be used to define the "scope" of the project. SET-IT can be used to develop a more detailed project architecture that can be used to support Concept of Operations and System Architecture Document development. This is necessarily considerably more detailed and technical than the regional content, and focuses on:

• Stakeholders, their roles within the project, captured as their operational role with respect to physical objects ("owns", "operates", "installs", etc.) which address concerns related to responsibility and delivery of services to end users.


• Services offered - these address the "mission" concern, and are typically illustrated by service packages. In SET-IT, service package diagrams may be graphically customized and modified to address specific project implementation choices and constraints.


• Elements that are part of the project, including those that already exist and those that will be built as part of the project - like those in the regional architecture these are instantiations of physical objects from ARC-IT.


• Information exchanges between elements - these are instantiations of information flows, much like in the regional architecture.


• Relationships between stakeholders - these usually concern the delivery of services or the exchange of information. SET-IT affords the user the ability to document these graphically as well as in tabular form, and expands on the types of relationships, in particular to consider relationships between service providers and end users.


• Communications-specific content - communications stacks that are suitable for carrying information on each information flow, which can be used as system architecture content and directly drives the development of Interface Control Documents (ICD)


• Security-specific content - ARC-IT includes a FIPS-199 based analysis of all information flows and physical objects, which directly drives communications security requirements and device security requirements. This information is germane at the project level and can be used as part of ICDs and device specifications.


• Needs - Each service has a set of user needs that it meets. These can be tailored along with the service package
.

• Requirements - Needs trace to requirements, which are associated with functional objects. Functional objects are included in the physical objects in each service package. Once the project architecture is complete, functional requirements associated with all services can be extracted through SET-IT.

As projects are completed, the state of elements in the regional architecture should change from "planned" to "existing." Additionally, once a project succeeds, the SET-IT artifacts that drove its design should be available for other, similar projects, which in the long run should improve interoperability and speed of deployment. This content should be made available to other projects in the region or even to other deployers in other regions. This should also be fed back to the regional architect to maintain the regional architecture to support the next set of projects.

The architecture can also be used to identify the appropriate standards to consider and possible use to develop a project. The communications view in ARC-IT tracks over 1,000 standards from around the world including data and message definitions, physical standards, communications protocols, and other specifications that support interfaces. Both RAD-IT and SET-IT can generate outputs that show the standards and communications solutions for the interfaces in a project. The Standards Map page provides a visual way to see it from the other side, that is, by focusing on some of the key standards and seeing how they are related to different parts of the overall Intelligent Transportation System (ITS). Some of the entries on this diagram are not traditional standards but rather specifications made available and maintained by a community not licensed as a standards development organization (SDO). Most of these communities still have well defined governance processes and practices so should be considered similarly to standards published by SDOs.