Software standards will be provided by a 2-layer Application Program Interface (API) as shown above.

Several "managers" have been identified representing sets of services that the APIs need to address. These service sets are:

User Interface
Database/Storage Management
Discrete I/O
Serial I/O
Startup Management

Separating Layers 1 and 2 allows ATC manufacturers to minimize their software efforts. Layer 2 can be provided by third parties if desired. In general, Layer 2 is presented as the primary application level API while Layer 1 is viewed more as an implementation detail of the Layer 2 interface.

ATC software API definitions and requirements are developed and specified separately from the 2070 specification. The APIs must support the 2070 as specified, but the specification and development efforts are separate. The scope of "compliant ATC platforms" includes but is not limited to the 2070.

API and application software implementations may be provided by hardware suppliers, software suppliers, end-user agencies or any combination of those.

APIs are defined as sets of ANSI C function interfaces and data definitions. For Layer 2, corresponding C++ class definitions will also be defined.

API implementations will be distributed as either ANSI C headers, linkable function libraries or as C++ class definitions and linkable class libraries.

The ATC committee must decide how to present and promote these APIs as an ATC standard. It is suggested that these APIs will be viewed as the only acceptable ATC standard, while recognizing that other platforms may be used in ITS applications.

Enables basic platform independence for application software. Provides lowest common denominator to support common application software across heterogeneous ATC platforms.

Encapsulates platform-dependent services (hardware/OS); therefore, the implementation is specific to each ATC platform.

Interface represents lowest level reasonable to support the general class of ATC/ITS applications. Assumes a basic set of features/services is available on host platforms.

The capability to support this API would be one requirement for an ATC to be compliant with a national standard. This capability, however, does not in itself define compliance. Other requirements needs to be defined to identify the features/capabilities needed to support the API and the intended range of ITS applications (i.e. performance, system services, I/O capabilities, storage media, etc.).

Implementation will be provided as a set of linkable ANSI C function libraries with appropriate headers.

Runs on top of Layer 1. Implementation is dependent on Layer 1 interfaces only. Code is directly portable to any ATC platform providing Layer 1 services.

Enables multiple application support, i.e. multiple compliant applications from multiple suppliers can run cooperatively on any ATC platform with this API.

Handles resource sharing among applications.

Provides common low-level application functionality to manage application cooperation, to enhance system performance, and/or to ease application development. Any such functionality must be low-level, general purpose, and flexible.

Encapsulates Layer 1 interface. Applications written to access Layer 2 may not directly access Layer 1.

May be provided either as an ANSI C function libraries or as a C++ class libraries.

 

Perform specific end-user tasks: intersection control, sign control, ramp metering, communications, data collection, etc.

Single applications may run directly on the Layer 1 API, although this should generally be discouraged. Applications designed to run cooperatively must interface strictly with Layer 2.

Applications are separate and outside the scope of the APIs. APIs may assume and accommodate services required to implement the general class of ITS applications, but no assumptions should be made about application architecture.

ATC Home Page