Post-Contract Certified Signaling Integration Partner Detail Document

Command Alkon
Signaling Specification Services
Version 1.94
Last Updated June 23, 2016
1
Copyright ©2016 Command Alkon Incorporated and/or its affiliates. All rights reserved.
The contents of this document are for informational purposes only and are subject to change without notice.
Command Alkon Incorporated ("CAI") may, without notice, modify its products in a way that affects the
information contained in this publication.
CAI HEREBY DISCLAIMS ALL REPRESENTATIONS OR WARRANTIES EITHER EXPRESSED OR

IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF
MERCHANTABILITY, TITLE, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR
PURPOSE. In no event will CAI be liable for any direct, indirect, or consequential damages arising out of
the use of, inability to use, or implementation of any information contained in this publication, even if CAI
has been advised of the possibility of such damages, or for any claim by any other party.
The information contained herein is subject to change without notice and may contain inaccuracies or
errors. CAI assumes no responsibility for any errors that may appear in this document. This publication is
intended only for the direct benefit of authorized users of CAI products. This publication may not be used
for any purposes other than those for which it is provided, and it is subject to the terms of the applicable
software license or subscription agreement. This publication and the information disclosed herein is the
property of CAI, and, except for rights granted by written consent, may not be disclosed, disseminated, or
duplicated in whole or in part.
Command Alkon Incorporated

1800 International Park Drive, Suite 400
Birmingham, AL 35243-4232
(205)879-3282
www.commandalkon.com
COMMANDseries (and the names of its components, such as COMMANDconcrete and

COMMANDnetwork), Spectrum, Eagle, and COMMANDbatch are trademarks of Command Alkon
Incorporated. All rights reserved.
Microsoft and Windows are trademarks of Microsoft Corporation. Other names may be trademarks of their
respective owners.
2
Command Alkon Signaling Specification Services................................................. 4
SECTION ONE: GENERAL INTERFACE OVERVIEW ....................................................... 4
I. Introduction ................................................................................................................... 4
II. System Overview ......................................................................................................... 4
III. Communication Overview ........................................................................................... 4
IV. Transactions ............................................................................................................... 5
V. XML Description........................................................................................................... 7
SECTION TWO: INTERFACE DETAILS.............................................................................. 8
I. Messages encryption and format.................................................................................. 8
II. XML Transport Structure Definition .............................................................................. 9
III. XML Transport Field Requirements and Descriptions ................................................ 9
IV. Transaction Category, Type and Subtype ................................................................. 17
V. Message Description Examples................................................................................. 19
VI. Message Examples .................................................................................................. 21
3
Command Alkon Signaling Specification
Services
SECTION ONE: GENERAL INTERFACE OVERVIEW
I. Introduction
The COMMANDfleet Mobile Signaling Interface is designed to provide a vehicle tracking
interface between the COMMANDseries application and Mobile Signaling providers. The
interface maximizes truck utilization, delivers accurate truck analysis information and
improves job site management; while minimizing IT time and costs. The interface is a
vehicle/fleet data collection tool that delivers real-time and historical vehicle event and
location information for your fleet management solution.
II. System Overview

COMMANDfleet sends and receives vehicle based data derived from both driver initiated
actions and GPS sensors, and provides a flexible tool for data mining and presentation. An
important piece of COMMANDfleet is the COMMANDsignal Integration Server (CSIS)
component that creates the transactional interface providing stability, scalability, and
serviceability. Incoming messages from trucks will cause the trucks to move automatically
on the COMMANDconcrete Truck Tracking screen without any additional action by the
dispatcher. Trucks routing and location information can be displayed on a map screen from
within COMMANDseries using GPS status information. The interface will also allow for
messages to be sent from the truck to the dispatch screen and from the dispatcher to the
truck; the interface allows truck mounted signal units to communicate directly with
COMMANDconcrete, Truck Tracking and mapping software.
III. Communication Overview

The movement of data between elements of the CSIS system is crucial to the proper
functioning of the system. An XML based transport mechanism was developed so that this
movement of data could be well defined. The XML data movement is accomplished using
Command Alkon Signaling Specification Services 4

the MSMQ mechanism from Microsoft. MSMQ implements asynchronous
communications by enabling applications to send messages to, and receive messages from
message queues. These queues are key to the overall communication between the Signaling
System and CSIS. The message queues protect messages from being lost in transit and
provide a place for receivers to look for messages when the receivers are ready to receive
them. The Signaling System will place messages in one queue for consumption by the CSIS
system and read for outbound messages from a second queue. The queue names are defined
within CSIS as part of the overall system set-up.
MSMQ has the ability to manage communications in several formats; however we have
chosen to utilize solely the queue approach for message management. By utilizing MSMQ
in this fashion we are able to accomplish the de-coupled design and allow for deployment of
the objects on heterogeneous hardware separated by a LAN or WAN connection.
IV. Transactions
The COMMANDseries Integration Server defines a transaction as any well-formed data
packet either inbound from a vehicle or outbound to a vehicle. Transaction data will traverse
the CSIS architecture as XML formatted messages that will be passed to and from
architecture components via the MSMQ mechanism defined above. A transaction may
elicit a response from the CSIS that in turn creates additional transactions that will traverse
the system. Every transaction within the system will have a unique transaction identifier
associated with it and each transaction will be stored within the CSIS database. Transactions
are the core of the CSIS system in the same way that orders and tickets are at the core of
COMMANDseries.
The following are the transactions that are moved from system to system and the expected
response for each:

Response Response
From Truck To Truck Description Required Originator
In Service When a truck comes into No
service to start the day an in-
service message is sent from
the truck to
COMMANDseries
Loading Message from the truck once No
loading begins
To Job The Signaling system should No
send To Job Message from the
truck when loading is
complete and the truck has left
the plant
On Job When the truck arrives at the No
job site the signaling system
should send an On Job
message
Pour When the truck begins to pour No
a Pour message is sent
Wash When the truck begins to wash No
on the job site a Wash message
is sent
To Plant When the truck has finished No
the wash task and leaves the
job site the signaling system
should send a To Plant
message

Response Response
From Truck To Truck Description Required Originator
At Plant When the truck arrives at the No
plant the signaling system
should send an At Plant/In
Yard message
Out of Service When the truck is out of No
service for the day an Out of
Service message should be sent
Driver Log In When the driver logs into the No
truck a message should be sent
Text and Coded We will both send and receive Yes Vehicle
Messages text and coded messages to the followed by
truck and back from the truck User
Vehicle Stopped and An alert to indicate that the No
Vehicle Started vehicle has made an unplanned
stop and when it restarted after
an unplanned stop
Text and We will both send and receive Yes Vehicle
Coded text and coded messages to the followed by
Messages truck and back from the truck User
GPS The system will poll the truck Yes Vehicle
Coordinates as needed and expect GPS
coordinates in response
GPS Coordinates The system expects to receive Yes Vehicle
updated GPS location for the
truck on predefined intervals
Leftover Concrete Leftover concrete message and No
amount should be sent from
truck
Water Added Water was added to the mix No
V. XML Description
This section will become available once a contract with Command Alkon has been signed.
The XML message is sub-divided into multiple groups; Header, Vehicle/Unit Identification
Data, and Transaction Data.
1. Header: The Header contains information pertaining to the type and formatting of
XML contained within this block.
<?xml version="1.0"?>
<cmdsig_xml_msg
xmlns:xsd="htThird Party://www.w3.org/2001/XMLSchema"xmlns:xsi="htThird Party://www.w3.org/2001/
XMLSchemainstance">
</cmdsig_xml_msg>
2. Vehicle/Unit Identification Data: This section contains the identifying the
originating source of data. (As described by Number 1 of III. XML Transport Field
Requirements and Descriptions in SECTION TWO: INTERFACE DETAILS)
<id>String(38)</id>

<vehicle_unit_code>String(16)</vehicle_unit_code>
<vehicle_ip_address>String(15)</vehicle_ip_address>
<signal_unit_code>String(3)</signal_unit_code>
3. Transaction Data: The Transaction Data will contain data relevant to the actual
business event that is occurring. (As described by Number 2 of III. XML Transport
Field Requirements and Descriptions in SECTION TWO: INTERFACE DETAILS)
The transaction section of the transport is as follows:
<transaction>
<date_time>DateTime (yyyy-mm-ddThh:nn:ss)</date_time>
<origin>String(3)</origin>
<category>String(4)</category>
<type>String(3)</type>
<subtype>String(3)</subtype>
<message> [**message data here**] </message>
</transaction>
4. Message Data: The Transaction Data optionally contains one or more sections
described as the Message Data. The format is dependent on the message content being
sent, which is expressed in the category, type, and subtype fields of the transaction. The
message always contains a GPS section, but this section can be empty. (As described by
Number 3 of III. XML Transport Field Requirements and Descriptions in SECTION
TWO: INTERFACE DETAILS)
<message>
<utc_date_time>2004-07-27T10:10:42</utc_date_time>
<text_message version="1.0">
<text>String(128)</text>
<text_message>
<gps version="1.0">
<latitude>Float(9999.9999)</latitude>
<latitude_hemisphere>String(1[N,S])</latitude_hemisphere>
<longitude>Float(99999.9999)</longitude>
<longitude_hemisphere> String(1[E,W])</longitude_hemisphere>
<satellites>Integer[2]</satellites>
<speed>Integer(999)</speed>
<speed_unit_of_measure>String(3[MPH,KPH])</speed_unit_of_measure>
<heading>Integer(999)</heading>
</gps>
</message>
SECTION TWO: INTERFACE DETAILS
I. Messages encryption and format

In order to retrieve the xml data from the message queue and translate it into a format that
can be read and understood by the COMMANDfleet application; the format of the
message queue needs to be set to activexmessageformatter.
Further, the data encryption needs to be set to either UTF 8 or UTF 16 format. UTF16
encryption format should be used when the data in the XML message can be represented in
either 1 or 2 bytes. The UFT 8 encryption format should be used to handle special character
and those that require more than 2 bytes to be represented.

II. XML Transport Structure Definition
<cmdsig_xml_msg xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi=http://www.w3.org/2001/XMLSchema-
instance version="1.0">
<id>String(38)</id>
<vehicle_unit_code>String(20)</vehicle_unit_code>
<vehicle_ip_address>String(15)</vehicle_ip_address>
<signal_unit_code>String(3)</signal_unit_code>
<transaction>
<date_time>DateTime (yyyy-mm-ddThh:nn:ss)</date_time>
<origin>String(3)</origin>
<category>String(4)</category>
<type>String(3)</type>
<subtype>String(3)<subtype>
<message>
<text>String(128)</text>
<text_message>
<gps version="1.0">
<latitude>Float(9999.9999)</latitude>
<latitude_hemisphere>String(1[N,S])</latitude_hemisphere>
<longitude>Float(99999.9999)</longitude>
<longitude_hemisphere> String(1[E,W])</longitude_hemisphere>
<satellites>Integer[2]</satellites>
<speed>Integer(999)</speed>
<speed_unit_of_measure>String(3[MPH,KPH])</speed_unit_of_measure>
<heading>Integer(999)</heading>
</gps>
</message>
</transaction>
</cmdsig_xml_msg>
III. XML Transport Field Requirements and Descriptions

1. Vehicle/Unit Identification Data: This section contains the identification data of the
originating source of the data.

FROM FROM Third
Field/Data type COMMANDfleet Party Description/Comments
id Mandatory Mandatory Unique ID number generated by the
Datatype: String(38) message creation entity (sender). This must
be expressed as a GUID of the format:
{130EB69E-CE15-406E-8DF7-
D22B945EF438}
It must be unique across all created
messages.
vehicle_unit_code Mandatory Mandatory Vehicle unit identification code. Referred to
Datatype: String(16) as a radio_code in COMMANDseries, this
value is the vehicle's unit identifying code.
This is the way in which the truck is
identified by the sending entity. This code
must be mapped in COMMANDseries to a
truck radio_code.
vehicle_ip_address Optional Not Used IP Address of the Mobile Data Unit in the
Datatype: String(23) vehicle, if applicable. This is used mostly as
a debugging tool to trace the progression of
cell IP changes over time and pinpoint
possible delayed or failed communication
due to changing addresses.
signal_unit_code Optional Mandatory Unit code assigned to truck in
Datatype: String(3) COMMANDseries
This is a segmentation value to distribute
truck load. If provided, this value will be
validated against valid signaling units
defined in COMMANDseries. If a valid
signaling unit; the truck signaling unit code
will be checked for consistency. If the truck
value differs, the truck will be updated with
the new value.
(This was historically used to track trucks
that moved between radio towers that were
configured as different signaling units.
Using modern cell technology and IP
transmission, this issue rarely applies to
current installations.)
2. Transaction Data: The Transaction Data will contain data relevant to the actual
business event that is occurring.

FROM FROM Third
Field/Data type COMMANDfleet Party Description/Comments
date_time Mandatory Optional The date and time when the transaction actually
Datatype: DateTime occurred, as opposed to when the event actually was
transmitted.
(yyyy-mm-
ddThh:nn:ss)
origin Mandatory* Optional Origin of the message; i.e. who sent it
Datatype: String(3) 1. DSP - origin is a Dispatch Workstation
2. CMD - Command Series
3. DRV - Driver
4. VEH - Vehicle Computer
5. EDT - Edited or added with transaction editor
6. PM - PM Rules Constructed
7. BLS - BLS Rules Constructed
8. BAT - Batch computer
10. UNK - Unknown
category Mandatory Mandatory See Section IV below
Datatype: String(4) Comment: The four character category will be
constructed using the type of message
<MSGCODE> from the vehicle message protocol
(S, M, T, P. …) as the first character plus the
directional movement of this message relative to
CSIS. For example an Inbound (SIN) message will
be inbound from a vehicle to CSIS. An Outbound
(MOUT) message will be outbound from CSIS to a
vehicle
type Mandatory Mandatory See Section IV below
Datatype: String(3) Comment: Three character description of the type of
message this is: a text message, a status etc.
subtype Mandatory Mandatory See Section IV below
Datatype: String(3) Comment: Three character description as to the sub-
type of message this is, it will further describe and
refine the type of message.
3. Message Data: The Message Data contains the details of the specific events and
messages being transferred between systems.
UTC
FROM
Field/Data type COMMANDfleet TO Third Party Description/Comments
date_time Optional Not Used Event Time in UTC
Datatype: DateTime In the event that this is not provided or left blank
(yyyy-mm- the time to be used is the transition date_time.
ddThh:nn:ss)

Message Text
FROM
text Mandatory Mandatory Message text to be displayed at the vehicle.
Datatype: (String(128)) Limit of 128 Extended ASCII characters. Can
be blank.
Material Leftover
FROM
value Mandatory Not Used Numeric value of quantity of material leftover
Datatype: Float(9.99) Range 0 - 9.99
unit_of_measure Mandatory Not Used Unit of measure for the value provided
Datatype: 1. CM: cubic meters
(String(2,[CM,CY])) 2. CY: cubic yards
Acknowledgment
FROM
originating_id Mandatory Not Used Id of the original message that initiated/
Datatype: (String(38)) requires an acknowledgment; e.g. a text
message sent to a vehicle that requires a vehicle
and driver acknowledgment would require two
acknowledgments with the same message id
that was contained in the text message
originally sent from COMMANDfleet to the
Third Party System.

Negative Acknowledgment
FROM
originating_id Mandatory Not Used Id of the original message that initiated/
Datatype: (String(38)) requires an acknowledgment; e.g. a text
message sent to a vehicle that requires a vehicle
and driver acknowledgment would require two
acknowledgments with the same message id
that was contained in the text message
originally sent from COMMANDfleet to the
Third Party System.
description Optional Not Used Text describing the failure of the message. This
Datatype: (String(128)) will usually pertain to delivery or processing of
the message to allow the sender to log the
failure text.
retry Optional Not Used Allows indication of the possibility of the
Datatype: sender retrying the message; e.g. truck was out
(String(1[Y,N])) of range and could not be contacted within
expected time limits; sending later may in fact
contact the truck (value should be Y).
1. Y: Yes
2. N: No
Blank is assumed N; no retry is possible; e.g.
vehicle_unit_code is not valid or not on file.
error_code Optional Not Used Error code to define a unique failure condition.
Datatype: (String(3)) This is arbitrary and up to the sender.
Trip Packet
FROM
site_source Not Used Optional The starting point of trip.
Datatype: site
site_job Not Used Optional The delivery point of the trip. This may be a
Datatype: site blank section (<site_job />) if there is only a
source and destination for the trip; e.g. Dead
Heading from site to site.
site_destination Not Used Optional The ending point of trip. Normally the return
Datatype: site plant.

Site Datatype Details
FROM
id Not Used Optional The identity of the site. This is usually the
Datatype: String (10) plant code or job code. This can be blank if no
id is available for the type site records; e.g. a job
may not have an id but the plant always will.
Description Not Used Optional Verbal description of location
type Not Used Mandatory The type of site record. "plant" and "job" are
Datatype: String (1,[P,J]) the two currently supported types.
1. P: Plant
2. J: Job
"plant" is used to describe a source or
destination of a trip. "job" is used to describe
the destination of the material acquired from
the source plant.
gps Not Used Optional Describes the terrestrial location of the site
Datatype: gps (see below) using Latitude and Longitude of the location.
Latitude and Longitude entries of the section
may be blank indicating the exact location is
not known or currently not mapped. All other
entries in the standard GPS packet will be
blank; i.e. satellites, heading, speed, and
speed_unit_of_measure entries will be present
but will always contain no data.
address Not Used Optional The address of the site. This may be blank
Datatype: Address (see indicating no information is available for the
below) address of a site.
radius Not Used Optional The size of the zone considered to be the site.
Datatype: Integer (4) This is focused at the point indicated by the
longitude and latitude of the GPS section.
From that point, the site zone extends in a
circle with a radius of the length specified in
this entry. This entry may be blank if not
defined for the site.
radius_unit_of_measure Not Used Optional Site zone radius unit of measure.
Datatype: String (1,[F,M]) 1. M: meters
2. F: feet
This may be blank indicating if the radius is
not defined for the site. If the radius is
provided, this entry must contain a value.
prevailing_wage Optional Optional Indicates if the job is subject to prevailing wage
Datatype: (String(1,[Y,N])) law typically in NY and CA. Will be set to Y if a
state_job_number is present.
1. Y: Yes subject
2. N: Not subject

Site Datatype Details
FROM
state_job_number Optional Optional The state_job_number on the ticket indicates a
Datatype: String (32) prevailing wage job reference.
hauler_code Optional Optional The hauler_code on the ticket referencing the
Datatype: String (8) hauler record.

GPS Datatype Details
FROM
latitude Mandatory* Not Used Latitude in Decimal format;
Datatype: Float (9999.9999) DDMM.MMMM
Where:
DD is degrees from 0-90
MM is minutes from 00-59
MMMM is partial minutes from 0-9999
DD and MM must zero padded to the
specified size; e.g. 0201.456 where DD is 02
and MM is 01
*Blank allowed only if not valid.
satellite_hemisphere Mandatory* Not Used Latitude Hemisphere
Datatype: (String 1. N=North
(1,[N,S])) 2. S=South
* Blank allowed only if not valid.
longitude Mandatory* Not Used Longitude in Decimal Format;
Datatype: float (99999.999) DDDMM.MMMM
Where:
DDD is degrees from 000-180
MM is minutes from 00-59
MMMM is partial minutes from 0-9999
DDD and MM must zero padded to the
specified size; e.g. 05001.456 where DDD is
050 and MM is 01
longitude_hemisphere Mandatory* Not Used Longitude Hemisphere
Datatype: (String(1,[E,W])) 1. E=East
2. W=West
Satellites Optional Not Used Number of Satellites reporting to make the
Datatype: (Integer(2)) GPS information
Speed Optional Not Used Speed Value 0-999 if in KPY
Datatype: (Integer(3)) Speed Value 0-99 if in MPH
speed_unit_of_measure Mandatory* Not Used Speed Unit of Measure
Datatype: 1. MPH: Miles Per Hour
(String(3[MPH,KPH])) 2. KPH: Kilometers Per Hour
* Mandatory only if speed is provided. If no
speed is provided, this field can be left blank.
heading Optional Not Used Numeric Directional Heading
Datatype: (Integer(3)) Range 0-359 where 0 is north

Address Datatype Details
FROM
street Mandatory Not Used Street part of address.
Datatype: String (60)
city Mandatory* Not Used City part of address.
state_province Mandatory* Not Used State or province part of address.
postal code Mandatory* Not Used Postal code part of address
country Mandatory Not Used Country part of address. USA implied if left
Datatype: String (30) blank.
full_address Mandatory Not Used The full address as one string. In some cases,
Datatype: String (128) this may be the only field that is filled in; e.g.
_Plants only have non-discrete address, so only
the full_address field will be filled in.
Water Added Details

FROM
value Mandatory Not Used Amount of water added
Datatype: Float
unit_of_measure Mandatory Not Used Gallon/Liter
type Optional Not Used Water added method (HOSE, MANUAL)
IV. Transaction Category, Type and Subtype

The Category, Type and Subtype are used to identify the type of transaction data being
received. The Category is composed of two parts; the first letter indicates the type of
transaction that is being transmitted, the remaining letters indicate the direction of the
message, either inbound to COMMANDfleet or outbound to the Third Party. The Type
explains the actual message type within that category; and the subtype identifies the actual
event or status at the most granular level.
Example:
Cat: TOUT = Text Message Out
Type: TEX = Text Message
Subtype: FRE = Free Formatted Text

Category (Description) Type (Description) Subtype: Description
SIN (Status and ACK’s Inbound) STA (Status) ISV: In-service
LDS: Loading Started
LDC: Loading Complete
TJB: To Job
AJB: Arrive Job
POU: Pouring
WSH: Washing
TPL: To Plant
IYD: In Yard
OSV: Out of Service
DRV: Driver ACK
VEH: Vehicle ACK
SIN NAK NAK: Vehicle ACK
SIN MSG CAN: Canned mobile messages numbered
<STATUSNO> = 21 through 48
SIN VEH STP: Vehicle Stopped
SIN VEH STOP: Vehicle Started
TICK CON NEW: New trip (ticketed)
(Trip Packet - Ticketing) CHG: Change to the trip
CAN: Trip canceled (ticket canceled)
OR: Deadheading to another plant
TOUT TEX FRE: Free formatted text
(Free Text Outbound) (Text)
MOUT (Message Outbound) NUM (Numeric/ PSB: Press Button <MSGNO>=00
Coded) RSP: Return to Same Plant <MSGNO>=01
CLD: Call Dispatch <MSGNO>=02
CWL: Call When Loaded <MSGNO>=03
WSH: Wash Truck <MSGNO>=04
ULO: Use Leftover <MSGNO>=05
CMG: Check Message <MSGNO>=06
RDP: Return Different Plant <MSGNO>=07
LBR: Lunch/Break <MSGNO>=08
CFB: Call For Balance <MSGNO>=09
LLD: Last Load <MSGNO>=10
DLO: Dispose Leftover <MSGNO>=11
CLM: Cancel Last Message <MSGNO>=15
POL: Request GPS coordinates <MSGNO>=16
PIN (GPS Coordinates Inbound) GPL (GPS Poll) GPL
GIN (GPS Inbound. Unsolicited GPL GPS
GPS sent on interval)
LIN (Leftover Inbound) LEF (Leftover) LEF

V. Message Description Examples
All examples assume the entire XML transport is provided for each message type. Each
example only shows the specific message pieces that change based on a particular inbound
or outbound message.
Example: Third Party receives Free Formatted Text Message from COMMANDfleet:
<cmdsig_xml_msg xmlns:xsd="htThird Party://www.w3.org/2001/XMLSchema"xmlns:xsi=htThird Party://www.w3.org/
2001/XMLSchema-instance version="1.0">
<id>{67185627-1383-44C3-B24D-84FEF4626710}</id>
<vehicle_unit_code>12345678</vehicle_unit_code>
<vehicle_ip_address></vehicle_ip_address>
<signal_unit_code>10</signal_unit_code>
<transaction>
<date_time>2007-03-05T05:18:16</date_time>
<origin>CMD</origin>
<category>TOUT</category>
<type>TEX</type>
<subtype>FRE<subtype>
<message>
<text>Return to plant</text>
<text_message>
</message>
</transaction>
</cmdsig_xml_msg>
Of note in the above example:

• Messages received by the Third Party System sent from COMMANDfleet:
 Will not contain a GPS section, since it is not pertinent to an outbound message to
the truck.
 Will not contain Vehicle IP address information.
• XML Tags that are message type specific are:

 Category
 Type
 Subtype
 Message
• All other tags are pertinent to the message being sent at the time it is sent.
 Id (new GUID)
 Vehicle_unit_code (destination vehicle radio unit code)
 Signal_unit_code (COMMANDseries signal unit code of the truck associated with
the vehicle_unit_code)
 Date_time (data and time the message was constructed and sent)
 Origin (the source system of the message)

Example: Third Party sends Free Formatted Text Message to COMMANDfleet:
<cmdsig_xml_msg xmlns:xsd="htThird Party://www.w3.org/2001/XMLSchema"xmlns:xsi=htThird Party://www.w3.org/
2001/XMLSchema-instance version="1.0">
<id>{67185627-1383-44C3-B24D-84FEF4626710}</id>
<vehicle_unit_code>12345678</vehicle_unit_code>
<vehicle_ip_address>10.10.220.100</vehicle_ip_address>
<signal_unit_code></signal_unit_code>
<transaction>
<date_time>2007-03-05T05:18:16</date_time>
<origin>DRV</origin>
<category>SIN</category>
<type>MSG</type>
<subtype>TXT<subtype>
<message>
<text>Request Lunch Break</text>
<text_message>
<gps version="1.0">
<latitude>3343.9875</latitude>
<latitude_hemisphere>N</latitude_hemisphere>
<longitude>08457.8764</longitude>
<longitude_hemisphere>E</longitude_hemisphere>
<satellites>4</satellites>
<speed>47</speed>
<speed_unit_of_measure>MPH</speed_unit_of_measure>
<heading>20</heading>
</gps>
</message>
</transaction>
</cmdsig_xml_msg>
Of note in the above example:

• XML Tags that are message type specific are:
 Category
 Type
 Subtype
 Message
• Text (message text)

• GPS filled in with all the vehicle information available, i.e. at the place where the
message request occurred. All other tags are pertinent to the message being sent at
the time it is sent.
 Id (new GUID)
 Vehicle_unit_code (destination vehicle radio unit code)
 Vehicle_ip_address (IP address of the vehicle at the time of the message request)
 Signal_unit_code if available (COMMANDseries signal unit code of the truck
associated with the vehicle_unit_code)

 Date_time (date and time that the message initiated at the vehicle)
 Origin (the source system of the message)

VI. Message Examples
1. Vehicle Start / Stop Message
Inbound from Vehicle to Command Series
Category: SIN
Type: VEH
Subtype valid values: STR or STP
COMMANDfleet Required Response: None
Data Flow:
XML Transport from Third Party to COMMANDfleet (example):

<type>VEH</type>
<subtype>STR</subtype>
<message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
2. Trip Packet Message Sent To Vehicle
Category: TICK
Type: CON
Subtype: NEW/CHG/CAN
Third Party Response Required: Vehicle Acknowledgments
Data Flow:
XML Transport from COMMANDfleet to Third Party (example):

New Trip Packet - new ticket (format is the same for the Trip Packet Change)

<category>TICK</category>
<type>CON</type>
<subtype>NEW</subtype>
<message>
<trip_packet version="1.0">
<site_source>
<id>001</id>
<type>P</type>
<gps version="1.0">
<satellites></satellites>
<speed></speed>
<speed_unit_of_measure></speed_unit_of_measure>
<heading></heading>
</gps>
</site_source>
<site_job>
<id></id>
<type>J</type>
<gps version="1.0">
<speed></speed>
<heading></heading>
</gps>
<prevailing_wage>Y</prevailing_wage>
<state_job_number>12345</state_job_number>
<hauler_code>123ABC</hauler_code>
</site_job>
<site_destination>
<id>001</id>
<type>P</type>
<gps version="1.0">
<speed></speed>
<heading></heading>
</gps>
<address version="1.0">
<street></street>
<city></city>
<state_province></state_province>
<postal_code></postal_code>
<country></country>
<full_address>1800 International Park Dr Birmingham AL 35243 USA</
full_address>
</address>
<radius>300</radius>
<radius_unit_of_measure>M</radius_unit_of_measure>
</site_destination>
<trip_packet>
<gps version="1.0"></gps>

</message>
Cancel Trip Packet

<type>CON</type>
<subtype>CAN</subtype>
<message>
<site_source></site_source>
<site_job></site_job>
<site_destination></site_destination>
<trip_packet>
</message>
Deadhead Trip Packet - Plant to Plant Trip

<type>CON</type>
<subtype>CAN</subtype>
<message>
<site_source>
<id>001</id>
<type>P</type>
<gps version="1.0">
<speed></speed>
<heading></heading>
</site_source>
<site_job></site_job>
<site_destination>
<id>001</id>
<type>P</type>
<gps version="1.0">
<speed></speed>
<heading></heading>
</gps>
<address version="1.0">
<street></street>
<city></city>
<state_province></state_province>
<postal_code></postal_code>
<country></country>
<full_address>1800 International Park Dr Birmingham AL 35243 USA</
full_address>
</address>
<radius>300</radius>
<radius_unit_of_measure>M</radius_unit_of_measure>
</site_destination>

<trip_packet>
</message>
3. Vehicle Status Packet Message
(In Service, Loaded, To Job, On Job, Pouring, Washing, To Plant, In Yard, Out of Service,
Driver In Service)
Category: SIN
Type: STA
Subtype valid values: ISV (07), LDS (00), TJB (01), ABJ (02), POU (03), WSH (04),
TPL (05), IYD (06), OSV (07), DLI (09)
Data Flow:
XML Transport from Third Party to COMMANDfleet

(Inbound Status from Vehicle - To Job) which has 3 different <message> formats as
described below:
The example below is for in service message; however the format of <message> section is
same for ISV, LDS, TJB, AJB, POU, WSH, TPL
<type>STA</type>
<subtype>ISV</subtype>
<message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
The example below is for in yard (IYD) message which contains optional return location
information:
<type>STA</type>
<subtype>IYD</subtype>
<message>
<gps version="1.0">

<speed>47</speed>
</gps>
<return_location_id>2</return_location_id>
</message>
The example below is for the driver login message which contains additional driver
information:
<type>STA</type>
<subtype>DLI</subtype>
<message>
<driver_login version="1.0">
<driver_code>123</driver_code>
</driver_login>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
4. Vehicle Status - Driver / Vehicle ACK
(Return to Category/Type/Subtype)
(Return to XML definition)
Category: SIN
Type: ACK
Subtype valid values: DRV (13), VEH (15)
Data Flow:
XML Transport from Third Party to COMMANDfleet (Inbound Status from Vehicle-
Driver ACK):
<type>ACK</type>
<subtype>DRV</subtype>
<message>
<acknowledgement version="1.0">

< originating_id >{67185627-1383-44C3-B24D-84FEF4626710}</id>
</acknowledgement>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
<type>ACK</type>
<subtype>VEH</subtype>
<message>
<acknowledgement version="1.0">
<originating_id>{67185627-1383-44C3-B24D-84FEF4626710}</originating_id>
</acknowledgement>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
5. Transaction Status - Transaction NAK
Category: SIN
Type: NAK
Subtype valid values: NAK
Data Flow:
Driver ACK):
<type>NAK</type>
<subtype>NAK</subtype>
<message>
<negative_acknowledgement version="1.0">
< originating_id >{67185627-1383-44C3-B24D-84FEF4626710}</id>
<description>Truck code is not valid</description>
<retry>N<retry>
<error_code>10234</error_code>
</negative_acknowledgement>

<gps version="1.0">
<speed>47</speed>
</gps>
</message>
6. Vehicle Status - Inbound Canned Messages (21-48)
Category: SIN
Type: MSG
Subtype valid values: statuses 021-048
Data Flow:
Canned LED Message):
<type>MSG</type>
<subtype>021</subtype>
<message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
7. Vehicle Message - Inbound Text Messages
Category: SIN
Type: MSG
Subtype valid values: TXT
Dataflow:

XML Transport from Third Party to COMMANDfleet (Inbound Status from Vehicle-Text
Message):
<type>MSG</type>
<subtype>TXT</subtype>
<message>
<text>Test Message</text>
<text_message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
8. Free Formatted Text Message Sent To Vehicle
Outbound from Dispatch to Vehicle
Category: TOUT
Type: TEX
Subtype: FRE
Third Party Response Required: Vehicle and Driver Acknowledgements
Message tag has a maximum of 128 characters extended ASCII text.
Data Flow:
XML Transport from COMMANDfleet to Third Party (example):

<category>TOUT</category>
<type>TEX</type>
<subtype>FRE</subtype>
<message>
<text>Test Message</text>
<text_message>

</message>
9. Coded/Numeric Message Sent To Vehicle
Category: MOUT
Type: NUM
Subtype valid values: PSB (00), RSP (01), CLD (02), CWL (03), WSH (04), ULO (05),
CMG (06), RDP (07), CBR (08), CFB (09), LLD( 10), DLL (11), CLM (15), 021-099
Third Party Required Response: Vehicle and Driver Acknowledgments
For Message Codes 21-99 the message code will be sent in the Subtype, unless there is a
document format defined for the message code then message will be sent as a Free Form
Text Message.
Data Flow:
XML Transport from COMMANDfleet to Third Party (Numeric message to vehicle):

<category>MOUT</category>
<type>NUM</type>
<subtype>RSP</subtype>
<message></message>
Equivalent to:
<type>NUM</type>
<subtype>001</subtype>
<message></message>
10. Coded/Numeric Message - GPS Coordinate Poll Sent to Vehicle
Category: MOUT
Type: POL
Subtype valid values: POL (16)
Third Party Required Response: for Category MOUT, Type POL, Subtype POL
message the response will be the GPS Coordinates message Category PIN, Type GPL,
Subtype GPL.
Data Flow:
XML Transport from COMMANDfleet to Third Party (Poll for GPS Coordinates):
<type>POL</type>
<subtype>POL</subtype>

<message></message>
11. GPS Coordinates Poll Response Inbound Message
Inbound from Vehicle to COMMANDfleet in response to GPS poll request. This message
type is sent only as a response to a poll request that is received from the COMMANDfleet.
Category: PIN
Type: GPL
Subtype valid values: GPL
Third Party Required Response: None
Data Flow:
XML Transport from Third Party to COMMANDfleet (GPS Poll Response from Vehicle):
<category>PIN</category>
<type>GPL</type>
<subtype>GPL</subtype>
<message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
12. GPS Coordinates Inbound Message
Unsolicited inbound GPS coordinates from Vehicle.
(Return to Category/Type/Subtype)
(See GPS XML definition)
Category: GIN
Type: GPL
Subtype valid values: GPS
Data Flow:

XML Transport from Third Party to COMMANDfleet (GPS location from Vehicle):
<category>GIN</category>
<type>GPL</type>
<subtype>GPS</subtype>
<message>
<gps version="1.0">
<speed>47</speed>
</gps>
</message>
13. Material Leftover Message
Category: LIN
Type: LEF
Subtype valid values: LEF
Data Flow:
XML Transport from Third Party to COMMANDfleet (Leftover Message):

<category>LIN</category>
<type>LEF</type>
<subtype>LEF</subtype>
<message>
<leftover_quantity version="1.0>
<value>1.10</value>
<unit_of_measure>CY</unit_of_measure>
</leftover_quantity>
<gps version="1.0">

<speed>47</speed>
</gps>
</message>
14. Water Added Event Message
Category: XIN
Type: WAT
Subtype valid values: the status the vehicle was in when water was added
Data Flow:
XML Transport from Third Party to COMMANDfleet (Water Added Message):

<category>XIN</category>
<type>WAT</type>
<subtype>TJB</subtype>
<message>
<water_added version="1.0>
<value>5</value>
<unit_of_measure>GALLON</unit_of_measure>
<type>HOSE</type>
</ water_added >
<gps version="1.0">
<speed>47</speed>
</gps>
</message>

Post-Contract Certified Signaling Integration Partner Detail Document

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Post-Contract Certified Signaling Integration Partner Detail Document

Uploaded by

Copyright:

Available Formats

Command Alkon

Signaling Specification Services

CAI HEREBY DISCLAIMS ALL REPRESENTATIONS OR WARRANTIES EITHER EXPRESSED OR

Command Alkon Incorporated

COMMANDseries (and the names of its components, such as COMMANDconcrete and

SECTION ONE: GENERAL INTERFACE OVERVIEW

II. System Overview

III. Communication Overview

Command Alkon Signaling Specification Services 4

Command Alkon Signaling Specification Services 5

Command Alkon Signaling Specification Services 6

Command Alkon Signaling Specification Services 7

SECTION TWO: INTERFACE DETAILS

I. Messages encryption and format

Command Alkon Signaling Specification Services 8

III. XML Transport Field Requirements and Descriptions

Command Alkon Signaling Specification Services 9

Command Alkon Signaling Specification Services 10

Command Alkon Signaling Specification Services 11

Command Alkon Signaling Specification Services 12

Command Alkon Signaling Specification Services 13

Command Alkon Signaling Specification Services 14

Command Alkon Signaling Specification Services 15

Command Alkon Signaling Specification Services 16

Water Added Details

IV. Transaction Category, Type and Subtype

Command Alkon Signaling Specification Services 17

Command Alkon Signaling Specification Services 18

Of note in the above example:

• XML Tags that are message type specific are:

 Vehicle_unit_code (destination vehicle radio unit code)

 Signal_unit_code (COMMANDseries signal unit code of the truck associated with

 Origin (the source system of the message)

Command Alkon Signaling Specification Services 19

Of note in the above example:

• Text (message text)

 Vehicle_unit_code (destination vehicle radio unit code)

 Signal_unit_code if available (COMMANDseries signal unit code of the truck

associated with the vehicle_unit_code)

 Origin (the source system of the message)

Command Alkon Signaling Specification Services 20

XML Transport from Third Party to COMMANDfleet (example):

XML Transport from COMMANDfleet to Third Party (example):

Command Alkon Signaling Specification Services 21

Command Alkon Signaling Specification Services 22

Cancel Trip Packet

Deadhead Trip Packet - Plant to Plant Trip

Command Alkon Signaling Specification Services 23

XML Transport from Third Party to COMMANDfleet

Command Alkon Signaling Specification Services 24

Command Alkon Signaling Specification Services 25

Command Alkon Signaling Specification Services 26

Command Alkon Signaling Specification Services 27

XML Transport from COMMANDfleet to Third Party (example):

Command Alkon Signaling Specification Services 28

XML Transport from COMMANDfleet to Third Party (Numeric message to vehicle):

Command Alkon Signaling Specification Services 29

Command Alkon Signaling Specification Services 30

XML Transport from Third Party to COMMANDfleet (Leftover Message):

Command Alkon Signaling Specification Services 31

XML Transport from Third Party to COMMANDfleet (Water Added Message):

Command Alkon Signaling Specification Services 32

You might also like