Maui Regional ITS Architecture

Project Systems Engineering Analysis


This webpage describes the portions of a project systems engineering analysis that can be found in the Maui Regional ITS Architecture in more detail. The table below shows the requirements of a systems engineering analysis, as specified by 23 CFR 940.11(c).

Systems Engineering Analysis RequirementMaui Regional ITS Architecture
Identification of portions of the regional ITS architecture being implementedService Packages, ITS Elements, and Element Interfaces
Identification of participating agencies’ roles and responsibilitiesOperational Concept
Requirements DefinitionsFunctional Requirements (Technology Neutral)
Analysis of alternative system configurations and technology options to meet requirementsNot covered
Procurement optionsNot covered
Identification of applicable ITS standards and testing proceduresThe architecture includes identification of applicable ITS Standards
Procedures and resources necessary for operations and maintenanceNot covered

Portions of the Regional ITS Architecture Being Implemented
The first requirement for a project systems engineering analysis is to identify the portions of the regional ITS Architecture being implemented. This requirement may be satisfied by identifying any service packages, ITS elements, and data flows being implemented in a given project. To identify these services packages, including the ITS elements and data flows contained in a service package, navigate to Services By Stakeholder in the menu at the top of the Website. Next, select the appropriate stakeholder for the project. This will list the service packages that the stakeholder participates in. Select the appropriate service package for the project. If the appropriate service package is not readily apparent, descriptions of all service packages can be found under the 'Services' menu at the top of the screen, under Service Package Descriptions.

The service package webpages will provide complete information for the portions of the ITS Architecture being implemented. Take a screenshot of the service package diagram. If a diagram contains information not relevant to the project, it can simply be crossed out. Next, scroll down below the diagram to find relevant information for that service package instance. This will include a list of ITS elements in the diagram, as well as stakeholder roles and responsibilities and a list of architecture flows. As with the service package diagram, ITS elements, roles and responsibilities, and architecture flows not relevant to a project can simply be removed or crossed out in the Project Systems Engineering Analysis.

Participating Agencies' Roles and Responsibilities
The second requirement for a project systems engineering analysis is identification of each participating agency's roles and responsibilities. Roles and responsibilities ensure that each stakeholder is aware of the part they most play in the deployment, operation, and maintenance of ITS. Roles and Responsibilities are listed on the Website under each service package diagram. Navigate to Services By Stakeholder in the menu at the top of the Website. Next, select the appropriate stakeholder for the project. This will list the service packages that the stakeholder participates in. Select the appropriate service package for the project. If the appropriate service package is not readily apparent, descriptions of all service packages can be found under the 'Services' menu at the top of the screen, under Service Package Descriptions.

The service package webpages will provide complete information for the portions of the ITS Architecture being implemented. Each web page for a service package instance includes not only a service package diagram, but also lists out ITS elements, roles and responsibilities, and architecture flows in that service package instance. The List of Stakeholder Elements and Roles table lists each stakeholder, the name of the ITS Element included in the package, a Functional Area/Role, and a description of the functional area. The Functional Area/Role field lists each role for a given stakeholder in an ITS element. The Functional Area Description provides a more robust description of a stakeholder’s role in that ITS Element. Some stakeholders will have multiple roles for each ITS element, and may have multiple ITS elements for each project. Functional Area/Roles that are not germane to a project can be removed or crossed out.

Requirements Definitions
The third requirement for a project systems engineering analysis is requirements definitions. Functional requirements are a description of the functions or activities that will be performed by ITS elements. For the Kauai Regional ITS Architectures, these functions have been developed by using the functional assignments underlying the NITSA and the mapping from transportation services to the elements. Navigate to Services By Stakeholder in the menu at the top of the Website. Next, select the appropriate stakeholder for the project. This will list the service packages that the stakeholder participates in. Select the appropriate service package for the project. If the appropriate service package is not readily apparent, descriptions of all service packages can be found under the 'Services' menu at the top of the screen, under Service Package Descriptions.

The service package webpages will provide complete information for the portions of the ITS Architecture being implemented. Each web page for a service package instance includes not only a service package diagram, but also lists out ITS elements, roles and responsibilities, and architecture flows in that service package instance. The List of Stakeholder Elements and Roles table lists each stakeholder, the name of the ITS Element included in the package, a Functional Area/Role, and a description of the functional area. For each Functional Role/Area this is germane to a project, click on the Functional Area/Role for a list of functional requirements related to that Functional Area/Role. Functional requirements that are not germane to a project can be removed or crossed out.

Applicable ITS Standards
The last area of a project systems engineering analysis that can be found in the Regional ITS Architecture the Identification of applicable ITS Standards. Identification of testing procedures, the second part of this requirement, is not part of the Regional ITS Architecture. ITS Standards ensure that ITS Elements are interoperable, both within a stakeholders deployments, but also between multiple stakeholders. Navigate to Services By Stakeholder in the menu at the top of the Website. Next, select the appropriate stakeholder for the project. This will list the service packages that the stakeholder participates in. Select the appropriate service package for the project. If the appropriate service package is not readily apparent, descriptions of all service packages can be found under the 'Services' menu at the top of the screen, under Service Package Descriptions.

The service package webpages will provide complete information for the portions of the ITS Architecture being implemented. Each web page for a service package instance includes not only a service package diagram, but also lists out ITS elements, roles and responsibilities, and architecture flows in that service package instance. ITS Standards can be found by scrolling to the bottom of the service package webpage. The last set of information on the Service Package webpage is the List of Flows on this Diagram. Not all flows will necessarily be included in any given project - architecture flows that are not germane to a project can be removed or crossed out. Clicking on each architecture flow that are germane to a project provides a short description as well as a list of relevant ITS Standards for that architecture flow. For more information on these ITS Standards, consult the ITS Standards Webpage on the website under the 'Resources' tab and selecting ITS Standards.

 

The Hawaiian language uses two diacritical markings. The 'okina is a glottal stop; and the kahako is a macron. The State of Hawaii strongly encourages the use of Hawaiian diacritical markings. The National ITS Architecture tool, Turbo Architecture, does not allow for the Hawaiian diacritical markings to be input and as such, customized service package diagrams, operational concepts and other outputs from Turbo are unable to reflect the diacritical markings. To ensure consistency in this ITS Architecture website, no Hawaiian diacritical markings will be used.