Office of Operations
21st Century Operations Using 21st Century Technologies
Table of Contents

Real-Time System Management Information Program Data Exchange Format Specification — Implementation Guidance

5. Implementation Issues

At this point in the process, an implementer has identified the data concepts necessary for DXFS information interchange. This section provides a discussion of additional standards that should be identified in a DXFS-based implementation, plus a technical discussion of issues related to the transport of data concepts across a system interface.

Implementation is the process of translating a design into hardware and software components, or both (IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE, September 28, 1990, p. 38.). The first part of this chapter section will focus on documentation of the software engineering environment (software implementation and test) of the system interface. The topic of software implementation is outside the scope of this guide, and no attempt is made to show any coding examples. Software engineers should refer to the actual standard (e.g., NTCIP 2306 or NTCIP 2304) for additional information. The second part of this chapter section will focus on technical issues that need to be considered in a system interface design and implementation. This part includes a discussion of communications concepts that relate to the deployment of DXFS system interfaces.

5.1 A Communications Framework for DXFS

An example communications framework diagram showing the interrelationship of the key communications standards that would be used in a deployment is shown below.

Figure 3 is a graphic showing the communications framework for the Real-Time System Management Information Program (RTSMIP) Data Exchange Format Specification (DXFS). Layers are for Information Level, Application Level, Transport Level, Subnetwork Level and Plant Level. Areas indicate both National Transportation Communications for Intelligent Transportation Systems Protocol (NTCIP) 2306 flows and NTCIP 2304 flows, as well as wide area wireless and wireline.

Figure 3. Diagram. A Communications Framework for the RTSMIP DXFS.
(Source: Based on: NTCIP 9001 version v04, The NTCIP Guide, AASHTO / ITE / NEMA, July 2009, p. 12.)

The diagram above is based on the NTCIP Framework (NTCIP 9001 version v04, The NTCIP Guide, AASHTO / ITE / NEMA, July 2009, p. 12), which provides a common reference for the concept of a communications framework, and for definition of the communications levels defined below.

Each of the Communications Framework levels is described:

  • Information Level Standards. Information-level standards define information content exchanges, and include dialog, message, and data element definitions.
  • Application Level Standards. Application standards define the rules and procedures for exchanging information data.
  • Transport Level Standards. Transport standards define the rules and procedures for exchanging the application data between point A and point X on a network, including any necessary routing, message disassembly or reassembly, and network management functions.
  • Subnetwork Level Standards. Subnetwork standards define the rules and procedures for exchanging data between two adjacent devices over some communications media. This is equivalent to the rules used to exchange data over a cellular link versus the rules used to exchange data over a twisted pair copper wire.
  • Plant Level Standards. The Plant Level is shown in the framework only as a means of providing a point of reference. The Plant Level includes the communications infrastructure over which communications standards are to be used and will have a direct impact on the selection of an appropriate Subnetwork Level for use over the selected communications infrastructure. The ITS standards do not prescribe any one media type over another.

The communications framework presents alternatives for deployment. Other standards might be applicable for a given level, but these represent a starting point to ease communications architecture and design. The objective is to give project developers a head start in understanding which standards to specify and implement in developing a ITS communications solution.

5.2 Achieving Interoperability

Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged (NTCIP 9001 version v04, The NTCIP Guide, AASHTO / ITE / NEMA, July 2009, p. 42).

Interoperability is attained only if multiple networked systems implement the same protocols, dialogs, messages, and data content definitions, i.e., they implement the same system interface specification. Also, important is that deployers implement the same version of the standards.

The bottom 4 layers of the Communications Framework (Plant, Subnetwork, Transport, and Application) will provide two systems only compatibility, but not interoperability. It is adding in the Information level that allows two systems to exchange information and use the information exchanged, the key to interoperability.

At the information level, some standards support backward compatibility, such that a current version of the standard and a previous version may interoperate. However, if the standard does not provide a statement that backward compatibility is supported, then deployers will need to agree on a particular version of the standard to implement.

At the information level, deployers will need to agree on which information level standards to implement. For example, for transit management, TCIP and SIRI are not interoperable. Or, roadway weather described in TMDD is not interoperable with OASIS CAP weather alerts. These examples do not interoperate because interoperability relies on both centers implementing the same data concepts (dialogs, messages, and specific content of messages). TCIP and SIRI do not share a common set of data concepts, as does not TMDD and OASIS CAP. Therefore, deployers must agree on which specific information level standards and which data concepts shall be implemented.

The reader should note that there are two paths an implementation may take within the application level to connect the information level to the transport level. Within the application level, NTCIP 2304 (AP-DATEX) and NTCIP 2306 (AP-C2C XML), do not interoperate. Therefore, when building a DXFS interface deployers should consider which path to take: only one application level standard is typically selected for an implementation.

The transport level contains the TCP/IP standard. The TCP/IP has been described as the “Swiss Army Knife” of communications. It is an essential ingredient of interoperability that “glues” systems across an inter-network, or network-to-network infrastructure.

In the subnetwork and plant levels, to achieve interoperability, the connections between software, hardware, and electronics must exist to create a communications link between two systems. A few examples to illustrate systems that lack interoperability at the subnetwork follow: A 700 MHz radio system and a 800 MHz radio system will not communicate with each other, nor will PCS communicate with cellular telephones, nor GSM and CDMA cellular phone. Therefore, for a connection between any two units, one subnetwork standard must be chosen for each communication link, and that subnetwork standard must also provide a bridge to the plant level used.

5.3 Communications Dialogs Related Technologies

5.3.1 The Application Level: Defining Message Patterns, Message Encoding, and Message Transport

The information level standards referenced by the DXFS define dialogs, messages, data frames, and data elements. These information level standards also provide standardized XML schemas that define the structure and content of messages. And two informational standards, TMDD and TCIP, also provide ASN.1 schemas.

The application level standards define the mechanism of encoding and transport of messages between centers. Two NTCIP standards have been developed for center-to-center communications: Application Profile NTCIP 2304 (AP-DATEX), and Application Profile NTCIP 2306 (AP-C2C XML).

A brief introduction to NTCIP 2304 and NTCIP 2306 follows in the sections below. For readers interested in a discussion about the differences potential advantages of implementing either NTCIP 2304 or NTCIP 2306 are directed to read NTCIP 9001 NTCIP Guide, and/or both NTCIP 2304 and NTCIP 2306.

5.3.1.1 NTCIP 2304 Overview

The NTCIP 2304 is formally entitled Application Profile for DATEX-ASN (AP-DATEX). NTCIP 2304 references the ISO 14827 standard, which defines the rules for message exchanges, encoding, and transport for ASN.1-based communications definitions. NTCIP 2304 is based on the assumption that two centers are always connected. Therefore, common dialogs for connecting, logging in, and disconnecting are defined and required. Once connected, two centers share information using a request-response message pattern or subscription-publication pattern.

A number of ITS implementations projects are currently using the AP-DATEX protocols to transport XML data files.

5.3.1.2 NTCIP 2306 Overview

The NTCIP 2306 is formally entitled Application Profile for XML Message Encoding and Transport in ITS Center-to-Center Communications.

NTCIP 2306 –AP-C2C XML is based on the rules of message encoding and transport of the W3C’s (World Wide Web Consortium) Web Services Architecture. NTCIP 2306 provides a way to define messages (using XML Schema) and dialogs (using the Web Services Definition Language).

The NTCIP 2306 provides a way to specify Web Services Definition Language (WSDL) for the following combinations of message encoding and transport:

  • Simple Object Access Protocol (SOAP) over HTTP. Using SOAP-encoded messages over the hypertext transfer protocol (HTTP), centers will be able to describe and deploy center interfaces that support the request-response and subscription-publication message patterns.
  • XML over HTTP. Using XML-encoded messages over the HTTP, centers will be able to describe and deploy interfaces that support the request-response (by HTTP POST) and request-only message patterns (HTTP GET). HTTP POST is suitable for the exchange of messages (request-response), and HTTP GET is suitable for the request of an XML document by name.
  • XML over FTP. Using the File Transfer Protocol (FTP), centers will be able to describe interfaces that support XML document requests by name.

5.3.1.3 NCTIP 2306 – XML Direct

In addition, the NTCIP 2306 provides a one-way pattern used to access a file by name. Together, the one-way message pattern and FTP or HTTP define the XML Direct approach, a simple technique for file exchange.

5.3.1.4 Message Patterns

Message patterns are the building blocks of dialogs. Three types of basic or simple dialogs can handle a wide variety of situations, or a project may define complex dialogs to satisfy their special project requirements. The three basic building blocks of dialogs, or message patterns, are as follows:

  • One-way. A concept intended for bulk data transfer. This messaging pattern implements a request of an XML file by name. As FTP and HTTP have a built-in mechanism for requesting a file by name, there is no need to develop a specific message for this type of request. The one-way response is an XML-encoded file.
  • Request-Response. This message pattern supports the sending of a message followed by a response. This pattern implements a synchronous pattern of message communications.
  • Subscription-Publication. This message pattern supports a subscriber application performing an initial request-response to set up future asynchronous responses from an information publisher application.

Both NTCIP 2304 and NTCIP 2306 provide the request-response and subscription-publication message patterns. The one-way pattern is a development of NTCIP 2306.

5.3.1.5 Message Encoding

Message encoding defines the bit-byte representation of message information content (also called encoding). Messages are encoded into the bit-byte representation prior to the start of network transfer regardless of how the information is represented in the originating and destination systems. The message encoding formats of NTCIP 2306 and NTCIP 2304 are as follows:

  • NTCIP 2306 specifies two information encoding formats: XML and SOAP, both standards of the W3C, and an encoding format for compression, GZip, a standard of the IETF.
  • NTCIP 2304 specifies information encoding of ASN.1. These include BER (Basic Encoding Rules) and the NTCIP 1102 Octet Encoding Rules (OER) standard. In addition, projects have been encoding message content as XML.

5.3.1.6 Message Transport

The term message transport as it applies to the application level of standards should not be confused with the term as it applies to the communications framework, i.e., TCP/IP. From the application-level perspective, the message transport used in the message transfer is typically a TCP/IP application. A TCP/IP application is a well-known socket-based application as defined by the IANA Well Known Port Numbers (HTTP/FTP). The message transport mechanisms (TCP/IP applications) used in NTCIP 2304 and NTCIP 2306 are described as follows:

  • NTCIP 2306 describes two message transport mechanisms: HTTP and FTP, both standards of the IETF.
  • NTCIP 2304 specifies a transport mechanism based on the TCP Socket API. Clients and servers exchange messages in DATEX over TCP Socket 355.

5.3.1.7 Developing NTCIP 2304 Specifications

The following tasks are necessary to develop an NTCIP 2304-based dialog specification:

  1. Determine the dialogs that fulfill the project requirements. One approach is to document the dialogs using UML sequence diagrams.
  2. Select an encoding format (BER, OER, XML, or SOAP).
  3. Use the transport format TCP/IP.
  4. Select the ASN.1 data concept definitions from the information level standard that fulfill the project system interface requirements.

5.4 Integrating Legacy Systems

This section addresses special considerations and approaches for developing a DXFS system interface to a legacy system, including:

  1. Interfaces for systems that do not support TCP/IP.
  2. How to handle the situation of unavailable (or missing) data. Two cases will be cited:
    1. The system does not have the capability to collect the data.
    2. The system can collect the data, but the data is unavailable to be sent in a message.

5.4.1 Interfacing Systems that Do Not Support TCP/IP

TCP/IP is a data communications standard that is available on a wide variety of systems. Systems that need to provide an interface to external systems could benefit by providing TCP/IP connectivity. If your system does not support TCP/IP the deployers should consider purchasing equipment to modernize the legacy systems interface to other centers.

Several options are available to deployers implementing TCP/IP over serial lines and/or dial-up connections.

  • The first point is that NTCIP 2306 provides a mechanism for transfer of information using the file transfer protocol (FTP). FTP can be used over a dial-up connection.
  • And, second, the Point-to-Point Protocol (PPP) and Serial Line Internet Protocol (SLIP) are protocols for implementing TCP/IP over a serial connection (including dial-up).

5.4.2 Handling Unavailable or Missing Data

While the situation of handling unavailable or missing data is handled in TMDD, it is not expressly defined how to handle these situation in TCIP, SIRI, and OASIS CAP. Therefore, the DXFS addresses the issue of what happens when there is no data to support a required data element This section deals with how to encode mandatory data elements that do not have data available – i.e., those data elements that are mandatory in the information level standard, as well as those optional elements that have been deemed mandatory based on the specification. Lastly, the DXFS defines a null data element as a mandatory data element that contains a null value (i.e., no data).

5.4.2.1 Null Data Element Encoding in ASN.1

ASN.1 defines a mechanism, the NULL type, for encoding of null data values. Therefore, there is no need to tailor the ASN.1 definition.

5.4.2.2 Null Data Element Encoding in XML

For XML, the approach suggested by the TMDD Standard is to return an error message in cases where a system has missing information in a message.