FINAL_HSHQDN-17-R-0002_RPM_RP_RFP-Atch_14-PRIDE_ICD-2017-1-19.docx

Radiation Portal Monitor Project PRIDE Interface Control Document for Radiation Portal Monitors

Revision 0 - DRAFT

RJ Carter

July 13, 2016

Radiation Portal Monitor Replacement Program

RFP HSHQDN-17-R-0002

Attachment 14

TM-1097-DRAFT

PNNL-XXXXX

Prepared for the U.S. Department of Homeland Security Domestic Nuclear Detection Office under U.S. Department of Energy Contract DE-AC05-76RL01830

DISCLAIMER

This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor Battelle Memorial Institute, nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof.

PACIFIC NORTHWEST NATIONAL LABORATORY

operated by

BATTELLE

for the

UNITED STATES DEPARTMENT OF ENERGY

under Contract DE-AC05-76RL01830

Radiation Portal Monitor Project PRIDE Interface Control Document for Radiation Portal Monitors

RJ Carter

July 13, 2016

Prepared for the U.S. Department of Homeland Security Domestic Nuclear Detection Office under U.S. Department of Energy Contract DE-AC05-76RL01830

Pacific Northwest National Laboratory Richland, Washington 99352

TM-1097-DRAFT

PNNL-XXXXX

Revision Log and Approvals PRIDE Interface Control Document for Radiation Portal Monitors

Richard Carter, Responsbile Author

Kevin Dorow, Engineering Task Manager

Michael Bettinson, RPMP Manager

Note: Document approvals that were received via email are retained in the project records.

RADS ADC Identifier: xhndoL

Acronyms and Abbreviations

Page vii of vii Contents

Table Table 1. Data Dictionary 7

Scope This Interface Control Document (ICD) is intended for use by radiation detection equipment vendors to develop interfaces for interoperable systems that can be used by the U.S. Department of Homeland Security (DHS) to integrate equipment manufactured by different vendors into radiation portal monitor (RPM) systems to be used at U.S. ports of entry.

The ICD specifies the interfaces between the RPM control module and external systems. This document does not specify other interfaces related to the RPM system, such as the interface between individual sensors and the control module, the command and control interface, or the interface to analysis modules.

Overview This ICD defines a set of eXtensible Markup Language (XML) messages and supporting XML schemas (.xsd file extensions) describing the communication from the RPM command module to external systems.

Document Organization This document 1) lists the events that are expected to occur within an RPM system for which external systems will be interested in receiving data and 2) provides the structure for the XML messages that the RPM system will use to communicate that data to external systems. The messages will conform to an XML schema that is provided. This schema is an update to the N25 schema. The schema files and sample message files are included as attachments to this document.

Limitations and Restrictions This document is limited to specifying the use of XML, a text-oriented language, for interactions between an RPM system and external systems that use the data generated by the RPMs. It is not intended to define communications that occur between components within an RPM system.

Additional References ANSI N42.42-2012. American National Standard Data Format for Radiation Detectors Used for Homeland Security (Revision of ANSI N42.42-2006).

Domestic Nuclear Detection Office (DNDO). 2007. Interface Control Document 1 (ICD-1) for DNDO Radiation Measurement Files. January 19, 2007. Document Number 600-ALIPT-000019 v 2.00.

Domestic Nuclear Detection Office. 2006. Interface Control Document 2 (ICD-2) for DNDO Radiation Analysis Results. December 20, 2006. Document Number 600-ALIPT-000020 v 1.10.

Customs and Border Protection, 2014. DHS CBP N.25 Standardized Messaging Protocol. June 26, 2014. V 1.6.0.0.

Interface Requirements This section describes the communication interface between the RPM control modules and external systems. This section describes the steps needed to establish and sustain communications, and how XML messages are sent to the external systems.

Interface Identification and Description This ICD applies to the communications from the RPM control modules to external systems such as the local data archiving system or PRIDE system that transfers messages to the U.S. Customs and Border Protection (CBP) national RPM data repository.

Communication Mechanism While it is imperative to have ensured delivery of messages from the RPM system to any external systems, it should not be incumbent upon the control module to track which messages each external systems subscribe to and ensure that the correct messages are sent to each system. Instead, the control module will be responsible for posting the event messages to a commercial off-the-shelf (COTS) message queuing system such as IBM Websphere MQ or Microsoft MQ. The external systems will subscribe to the appropriate queues to receive messages. The message queue will ensure delivery of the messages to the subscribing external systems.

External systems, such as PRIDE, may request some types of information from the RPM system. The external system will post a message to a queue and the RPM system will respond to it.

Message Flow The control module will create messages in response to events that occur within the RPM system and will add these messages to an established, outgoing message queue. The control module will also monitor a second, incoming queue for request messages coming from external systems and will respond to those messages.

External systems, such as PRIDE, will subscribe to the outgoing message queue to receive the messages posted by the RPM system. PRIDE will forward messages to the CBP national RPM data repository.

XML Messaging The messages generated by the control module will adhere to the XML schema described in this document. This schema is a modification to the N25 messaging protocol currently used by the PRIDE system to transfer RPM data from ports of entry to the CBP national data repository.

RPM Events Messages are triggered by events in the RPM system. The RPM system will send a message for the event types described in the following sections.

SCAN

A SCAN event consists of a vehicle traversing a portal or otherwise being examined. One SCAN event is generated for each such traversal, resulting in a SCAN message. The SCAN message contains both the raw RPM data and any analysis results, including any alarms triggered by the SCAN event. Each scan will have a unique Scan ID, which is used to link other events, such as IMAGE and METADATA events to the scan.

IMAGE

An IMAGE event occurs when a visual image of a vehicle is taken during a SCAN or when a chart is created from data captured during a scan. One IMAGE event is generated for each image taken or created, and one IMAGE message is generated for each IMAGE event, and the type of image is specified within the message. The IMAGE message is linked to a SCAN message via the Scan ID field.

METADATA

A METADATA event occurs when an inspection officer enters data collected during an inspection such as driver information (name, license number, date of birth, etc.), cargo information (commodity, shipper, etc.), or inspection results. The METADATA message is associated with a specific SCAN message via the Scan ID field.

OCR

An OCR event occurs if an optical character recognition (OCR) system runs separate, but in parallel to the radiation detection system. An OCR event occurs when the OCR system produces a result. The OCR message is linked to a specific SCAN message via the Scan ID field.

OCRUPDATE

An OCRUPDATE event occurs when the results from an OCR system are manually updated to correct errors.

RELEASEDATA

A RELEASEDATA event occurs when a convoy, usually a train, exits a facility. The message associated with the RELEASEDATA event identifies the vehicles or containers in the convoy and includes references to the RPM scans for those vehicles or containers.

REQUEST

REQUEST events are generated external to the RPM system and are used by other systems to request the health status, threat level status, or configuration settings of the RPM.

BACKGROUND

A BACKGROUND event is generated on a timed basis, usually every 5 minutes. The message associated with the BACKGROUND event provides updated background radiation readings for an RPM.

ACK

An ACK event is generated when a user acknowledges a radiation alarm on an RPM.

CONFIG

CONFIG events occur upon a change to the configuration parameters of a device in the RPM system or in response to a REQUEST event.

THREATSTATUS

A THREATSTATUS event triggers the generation of a threat level report. These can occur on a timed basis, in response to a change in the threat level settings, or in response to a REQUEST event.

HEALTHSTATUS

A HEALTHSTATUS event triggers the generation of a health status report. These can occur on a timed basis or in response to a REQUEST event.

SYSEVENT

A SYSEVENT event occurs when there is a system error or event in the RPM system that requires logging, but does not require a dedicated event type. There are several subtypes of the system event:

· LOGON – Occurs when a user logs on to the RPM system.

· LOGOFF – Occurs when a user logs off of the RPM system.

· CONFIGACCESS – Occurs when a user accesses the configuration options in the RPM software.

· SYSPASS – Occurs when there is a change in the RPM system password.

· UPGRADE – Occurs when there is a software upgrade to an RPM system.

· RESTART – Occurs when an RPM restarts.

· SYSTEMEVENT – Is used for events that do not fall into one of the other categories.

N25 Messages Events occurring within the RPM system trigger the generation of XML messages. These messages adhere to a modified version of the N25 schema. The updated schema is tentatively being called N25 version 2.0.

Changes from N25 Version 1.45 Structural Changes Version 1.45 of the N25 schema is actually six schemas, one for each N25 message type. The schemas all use the same namespace, and include some redundancy. Each of the six schemas uses an include statement to reference the MessageHeader.xsd file, which, like the name implies, contains the definition for the message header that is included in each N25 message. Having six separate, overlapping schemas is problematic when writing software that utilizes the N25 protocol.

In the proposed version 2.0 of N25, the inclusion is inverted. The new EventMessage.xsd file defines the elements that are common across all N25. These are the document root element, <EventMessage>, and the elements <Message Header> and <MessageContent>. Each message type is still defined in its own file, and the EventMessage.xsd references these files via include statements. Elements of the N25 schema that are common across multiple message types, but not common to all messages, are defined in a new file called N25BaseDataTypes.xsd. This file is referenced in an include statement in each of the schema files for the individual message types. Every schema file is a valid XML schema file if its included files are present. This reorganization results in a single schema that supports all six message types.

The document element for all N25 messages has been changed from <MessageEnvelope> to <EventMessage>. The new name is intended to be more descriptive, and the change allows programs built to parse N25 messages to easily distinguish version 2.0 messages from messages built to an earlier version of the N25 schema.

XML Schema Best Practices The following XML schema best practices have been applied in an attempt to make the N25 schema easier to use and to incorporate into automated tools:

· The only elements defined at the root level of a schema are elements that are intended to be used as document elements. Since all N25 messages use the <EventMessage> element as the document element, this is the only element defined at the root level of the N25 schema.

· Element type definitions use distinct names. Prior versions of N25 used the same name for some type definitions and instances of elements that used that type definition.

· No attributes are defined at the top level of the N25 schema as this can cause problems with the namespace that applies to those attributes. Instead, attributes are defined within attribute groups or within the type definition that uses the attribute.

· Uniquely identify all schema components with the id attribute.

· Redundant definitions are combined. For example, the elements <ScanIdentifierData> and <DeviceIdentifier> are both defined in multiple locations in a prior version of the N25 protocol. Some of the definitions are identical, and some have slight differences such as a change in the order of the contained elements.

· Consistent naming:

· Inconsistent abbreviations are expanded.

· Enumerations are named the same as the element or attribute for which they enumerate values with a prefix of “enum.”

· Date and time values are typed as xs:dateTime.

· Unused type definitions are removed.

ANSI N42.42

The N25 schema has been updated to use the latest version of the ANSI N42.42 schema as of the writing of this document: version 0.0.54, dated February 1, 2012, also known as ANSI N42.42-2012. Because the ICD1 and ICD2 specifications predate this version of ANSI N42.42, the proposed changes to N25 do not adhere to ICD1 or ICD2. Content written to the older standard (N42.42-2006) will not validate against this updated N25 schema.

Data Dictionary Table 1. Data Dictionary

GeneralInstrumentMessage

Events

Appendix A – N25 Version 2.0 (proposed) Schema

The content of each of the XML files that make up the proposed N25 version 2.0 schema are listed below.

EventMessage.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="http://dhs.cbp.gov/ats/SFIGateway" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://dhs.cbp.gov/ats/SFIGateway" elementFormDefault="qualified" attributeFormDefault="unqualified">

</xs:documentation>

</xs:documentation>

</xs:schema>

N25BaseDataTypes.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="http://dhs.cbp.gov/ats/SFIGateway" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://dhs.cbp.gov/ats/SFIGateway" elementFormDefault="qualified" attributeFormDefault="unqualified">

</xs:schema>

DeviceHealthAndConfigMessage.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="http://dhs.cbp.gov/ats/SFIGateway" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://dhs.cbp.gov/ats/SFIGateway" elementFormDefault="qualified" attributeFormDefault="unqualified">

</xs:schema>

GeneralInstrumentMessage.xsd <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="http://dhs.cbp.gov/ats/SFIGateway" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://dhs.cbp.gov/ats/SFIGateway" elementFormDefault="qualified" attributeFormDefault="unqualified">