Logical Architecture*

The Logical Architecture defines the Processes (the activities and functions) that are required to provide the required User Services. Many different Processes must work together and share information to provide a User Service. The Processes can be implemented via software, hardware, or firmware. The Logical Architecture is independent of technologies and implementations.

Logical Architecture Components

The Logical Architecture consists of Processes (defined above), Data Flows, Terminators, and data stores. Data Flows identify the information that is shared by the Processes. The entry and exit points for the Logical Architecture are the sensors, computers, human operators of the ITS systems (called Terminators). These Terminators appear in the Physical Architecture as well. Data stores are repositories of information maintained by the Processes.

The Logical Architecture is presented to the reader via Data Flow Diagrams* (DFDs) or bubble charts and Process Specifications (PSpecs).

The DFDs are graphical presentations of the Processes, Terminators, Data Flows, and Data Stores in the architecture. The DFDs are organized hierarchically starting from highest-level activity "Manage ITS". High-level activities are then decomposed functionally through multiple levels to arrive at the fundamental ITS processes and activities.

The PSpecs are textual descriptions of the most rudimentary processes in the Logical Architecture. Each PSpec description consist of an overview, a set of functional requirements, and a complete listing of inputs and outputs. A system designer can use these descriptions as a guide to writing the specifications for the systems that will implement the processes described.

The "Processes" link in the figure above presents a list of all of the DFDs and the PSpecs defined in this version of the Architecture. Also included are the Subsystems from the Physical Architecture that utilize the PSpecs. All of the PSpecs and Subsystem entries are hyperlinked to detailed descriptions in this document.

Different users of the National Architecture will use the Logical Architecture presented here in different ways:

    Public Sector Agencies- most public sector employees will not be required to deal with the Logical Architecture directly, however they will be required to review the software operation to verify that it meets their requirements. They may use the Logical Architecture to write their own system and interface requirements specifications

    Consultants- must often create Logical and Physical Architectures that are traceable to their user's requirements. Hence, the linking and organization of the Physical and the Logical Architectures is of paramount interest to them. The additional detail provided by the Logical Architecture may also assist developers as they begin to implement a project

Data Flows Processes
Hypertext Architecture Version 6.0.0 generated on 4/23/2007 from the following databases
Physical Architecture dated 4/6/2007,
Logical Architecture dated 4/23/2007,
Market Packages dated 4/23/2007,
Security dated 4/20/2007,
User Services dated 4/9/2007,
AppMap dated 4/23/2007 and the
SDOMAP dated 4/23/2007