Physical Viewpoint

The Physical Viewpoint represents physical elements that operate in the field and the backoffice, the functionality contained within those elements, the roles elements play in delivering user services, and the connections between those elements.

The Physical Viewpoint is an engineering viewpoint: it lies closer to design than the functional viewpoint, and leads directly to the Communications Viewpoint. The bounds of an element in the Physical View are constrained by the Enterprise view (who owns, who operates etc.), informed by the Functional (what does it do) and ultimately specified in accordance with physical constraints.

All stakeholders will find the Physical viewpoint informative. The Physical provides the basis for Service Packages, which are a concise, comparatively easy to read and follow diagrammatic artifact that communicates notions of service delivery, functionality, information exchange and concerns related to those concepts. The Physical Viewpoint enables the engineer to answer questions such as:

• What physical entities are involved in the delivery of a given service?
• What interfaces are required between different physical elements?
• What functionality is allocated to physical entities?
• What are the security considerations for information exchanged between physical elements?
• What are the security considerations for physical devices?

The Physical Viewpoint defines the following objects:

• Physical Object (P-Object): Person, place, or thing that participates in ITS. Physical Objects are defined in terms of the applications they support, the processing they include, and their interfaces with other physical objects. They are grouped into five classes: Center, Field, Support, Personal and Vehicle. Physical Objects are defined with scope such that they are under the control of a single Enterprise Object.
  • Center: An element that provides application, management, administrative, and support functions from a fixed location not in proximity to the road network. The terms "back office" and "center" are used interchangeably. Center is traditionally a transportation-focused term, evoking management centers to support transportation needs, while back office generally refers to commercial applications.
  • Field: Infrastructure proximate to the transportation network which performs surveillance (e.g. traffic detectors, cameras), traffic control (e.g. signal controllers), information provision (e.g. Dynamic Message Signs (DMS)) and local transaction (e.g., tolling, parking) functions. Typically governed by transportation management functions running in centers. Field also includes connected vehicle roadside equipment and other non-DSRC wireless communications infrastructure that provides communications between mobile elements and fixed infrastructure.
  • Support: A center that provides a non-transportation specific service. Typically these are enabling functions, such as communications facilitation, security or management.
  • Personal: Equipment used by travelers to access transportation services pre-trip and en route. This includes mobile/handheld as well as desktop equipment owned and operated by the traveler.
  • Vehicle: Vehicles, including driver information and safety systems applicable to all vehicle types.
• Functional Object: The building blocks of the physical objects of the physical view. Functional objects group similar processes of a particular Physical Object together into an "implementable" package. The grouping also takes into account the need to accommodate various levels of functionality. Since Functional Objects are both the most detailed components of the physical view and tied to specific service packages, they provide the common link between an interface-oriented architecture definition and deployment-oriented applications. Functional Objects provide the functionality defined by P-Specs in the Functional View.
• Information Flow: Information that is exchanged between physical objects in the physical view. Information flows and their associated communication requirements provide the highest-level definition of interfaces. Information flows are related to entity relationships in the Enterprise View, and are more fully detailed in the Communications View. Information Flows are characterized by Flow Characteristics, which imply various communications protocol standards. They are always accompanied by a provision agreement relationship. Such relationships are formal if both participants are centers, support or field equipment. They are nearly always informal if between two mobile objects. If between mobile and fixed, the relationship may be formal if personalized or individually targeted information is exchanged.
• Triple: The combination of P-Object source, Information Flow and P-Object destination. The Triple is the foundational structure used to define an interface.
• Subsystem: Physical object with defined functionality. Inside the ARC-IT system boundary.
• Terminator: Physical object without defined functionality. Outside the ARC-IT system boundary.
• Service Package (Physical) Diagram: A summary diagram illustrating all of the P-Objects, Functional Objects and Information Flows likely needed to support the Service Package. Service Package diagrams may support more than one use case. Physical Service Package diagrams use the following graphics to illustrate physical elements:

Physical view service package implementation diagrams illustrate the subset of a service package that meets all user needs of the service package using a particular approach.