ATC Software Standards Approach:
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:
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
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
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
Layer 1: "Platform Interface" API
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.
Layer 2: "Application Environment" API
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.
Layer 3: "Applications"
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.