JSON

JSON, pronounced "Jason", is a standard syntax for encoding structured data in a programming language independent and human readable format. Every OKM is a valid, well-formed JSON object. This specification defines the proper semantics of constructing OKMs using JSON.

There are many excellent references for JSON syntax, but for the purposes of this document several basic syntax elements will be defined:

• Opening and closing curly braces {} is an unordered object.

• Opening and closing square brackets [] is an ordered array.

• Name/value pairs are called fields.

• A name is a string.

• A value may be an object, array, number, string, Boolean, or null.

• Fields may be nested in the value of other fields.

• A set of fields encapsulated by top-level curly braces is called a message.

Example OKM (this example can be improved, and more examples should be added to spec):

The message is

_src is the name of an array where the first element's value is the string 0102030405060708.

_cmd is the Name of a Field whose Value is the string wr.

_id is the Name of a Field whose Value is the integer 192.

_ts is the Name of a Field whose Value is the string 2019-12-26T14:40:00.

_pld is the Name of a Field whose Value is the object {"_hbt":{"door":56}}.

_hbt is the Name of a Field whose Value is the object {"door":56}.

door is the Name of a Field whose Value is the number 56.

_crc is the Name of a Field whose Value is the string 8813.

Hierarchical Path Notation

A simple path notation, used by the CWL, is used to identify fields within the hierarchical structure of an OKM.

A dollar sign $ represents the field name of the root level message.

A dot . separates field names of additional levels.

From the previous section, $._pld._hbt is the path to the object value {"door":56}.

And, $._pld._hbt.door is the path to the integer value 56.

All transported messages must be valid JSON syntax and include NULL termination. Vendor specific extensions to OKMs must adhere to the specification rules.

Maximum Length

The maximum message length is 1000 bytes including NULL termination.

Escape Sequences

JSON strings, which includes field names, must follow the JSON standard as it pertains to escaping special characters otherwise the resulting JSON message will not be valid. Field names should only use printable, non-control characters.

Except for normally escaped string characters, non-printable ASCII characters should be encoded as a JSON Unicode escape sequence \u00XX. This keeps the OpenKitchen JSON message human readable and minimizes the potential for extraneous control sequences to cause unexpected problems during message creation, transmission, and processing.

Unicode Character Sets

The current implementation of the CWL interprets strings as a set of 8-bit ASCII characters and does not natively handle Unicode character sets.

OKE that support Unicode character strings, and which intend to transfer those strings to and from the OKC will use the Base64 encode those strings, essentially treating them as binary data, when creating OKMs. The OKE data dictionary will specify which fields contain Unicode strings, the specific Unicode encoding (UTF-16, etc.) and that those strings are Base64 encoded within the OKM.

Field Ordering

Except for arrays, the order of fields within a JSON message must not confer information and must not be interpreted to convey information. For example, a source generating a JSON message cannot ensure the destination will process the fields of the message in a specific order.

The following two JSON messages contain the same information and destinations handling these messages may process either _cmd or _id first followed by the other:

{"_cmd":"wr","_id":5612}

{"_id":5612,"_cmd":"wr"}

However, the source can be certain that fields organized in a nested hierarchy are processed by the destination within the context of the hierarchy.

Use an array when the order of data and its processing matters.

Encoding Binary Data

Binary data, data containing mainly non-printable characters, shall be encoded either as an ASCII hexadecimal string or as a Base64 encoded string.

ASCII Hexadecimal String

Binary data should be encoded as an ASCII hexadecimal string when the data can be decoded into a meaningful value that is helpful for debugging. For example, a 2-byte bit-field value such as 0x6A05 should be encoded as the string 6A05 in the JSON message. A leading “0x” will not be prepended to the string. ASCII letters should be uppercase.

Multi-byte integer values should be encoded in big endian format.

Base64 encoding

Binary data should be encoded as a Base64 string when the data does not have an obvious meaningful value for debugging or when the amount of binary data is large. Base64 encoding increases the size to represent a binary string by about 1 1/3 of the original data, whereas an ASCII hexadecimal string would double the size. A typical use case for Base64 encoding would be to represent a portion of a file or firmware image.

The CWL substitutes the pipe character | for the standard forward slash character / when encoding and decoding Base64 strings. This is done to eliminate the required escaping of the forward slash within the JSON string. This makes the length of the Base64 encoded string more predictable and results in less memory consumption.

Whitespace

Although whitespace, including newlines and carriage returns, are allowed between JSON elements they do not add any meaning to the data being represented and will consume additional bandwidth and memory that is at a premium on many embedded devices and low bandwidth networks.

Therefore, it is strongly recommended that all whitespace characters whose sole purpose is to make the JSON format nicely, be removed before the message is transported between the OKE and the OKC.

ConnectWare Library

https://sitesage.atlassian.net/wiki/x/Z4BFHQ

The CWL includes a memory efficient JSON parser and emitter that can be used by implementors for processing and generating CWMs.

Field Names

Standard Field Names

The names of all standard fields will be preceded by an underscore.

Custom Field Names

Custom field names shall not begin with an underscore character.

Custom defined field names shall not contain a period/dot character.

It is recommended that field names defined by OKE vendors be descriptive and short.

One of the benefits of using JSON is that a human can readily read and decode the message. So meaningful field names are essential. However, very long field names can unnecessarily waste bandwidth and memory. The recommendation is that field names are generally 3 to 5 characters in length.

Hierarchical Complexity

JSON syntax permits hierarchical nesting of elements that helps represent the logical organization of data.

However, this can greatly increase the memory and time requirements for parsing a message.

For incoming messages generated by the OKC and meant to be consumed by the OKE it is recommended to keep JSON data nesting to a minimum. Typically, a message would have no more than 3-4 levels of nesting at maximum.

For outgoing messages generated by the OKE and meant to be consumed by the OKC significant data nesting should still be avoided to keep processing overhead low. Typically, a message would have no more than 3-4 levels of nesting at maximum.

Standard fields provide the common language for OKMs. Vendor specific extensions to OKMs allow an infinite variety of information to be represented and exchanged.

Field definitions use hierarchical path notation to explicitly define the relationship fields have with each other.

Command - _cmd

The $._cmd field has a string value of either rd or wr.

This field is present in every message regardless of source.

Write - wr

The wr value indicates that the source is writing the message to the destination.

When the OKC writes a message to the OKE, the equipment should interpret the $._pld field as the context for changing the state of the equipment’s configuration, operating mode, or other attributes.

When the OKE writes a message to the OKC, the cloud should interpret the $._pld as the data to record or process in the cloud.

Read - rd

The rd value indicates that the source is reading data from the destination.

When the OKC sends a read message to the OKE, the equipment should interpret the $._pld as the context to read specific data associated with the equipment. This allows the cloud to read configuration, operating mode, or other attributes from the equipment.

When the OKE sends a read message to the OKC, the cloud should interpret the $._pld as context for reading specific data from the cloud.

Transaction IDs - _id, _rid

$._id and $._rid are unsigned 16-bit transaction IDs whose value is represented as an integer.

Every outgoing message will have a unique $._id value assigned to it. Implementations will minimize the reuse of $._id values.

The $._rid field is included by OKE when an outgoing message was in reaction to a specific incoming message from the OKC.

The OKC can match the message received from the OKE to its original message.

Timestamp - _ts

The $._ts field’s value is local time formatted as an ISO 8601 string. The time zone designator is not required. Time must include seconds and may optionally include sub-second resolution as appropriate. $._ts represents the time that the message was created and should be coincident to the latching of varying data values represented in the value of $._pld.

Every outgoing message from OKE will have a $._ts field.

Payload - _pld

The $._pld field’s value is a variable object. The context of the $._cmd read or write is determined by the $._pld field’s value.

Every outgoing message will have a $._pld field.

Developers for OKE systems using the CWL will primarily be focused on creating and processing JSON encoded telemetry and configuration contained in the $._pld value.

Priority - _pri

The $._pri field is included when the message should be sent via the PSFQ and the $._rid field is not applicable. The value is the Boolean true.

The $._pri field is only included by OKE having a CWM, since it is used by the CWM to place the message into the PSFQ.

Store and Forward Queue - _sf

The $._sf field’s value is an integer representing the total number of queued store and forward messages in both the PSFQ and TSFQ. This field is updated in real-time right before a message is delivered to the cloud.

Only OKE or its CWM should include this field in a message.

Store and Forward Queue - _psf

The $._psf field’s value is an integer representing the total number of queued store and forward messages in the PSFQ. This field is updated in real-time right before a message is delivered to the cloud.

Only OKE or its CWM should include this field in a message.

Inbound Store and Forward Queue - _isf

The $._isf field’s value is an integer representing the total number of queued store and forward messages in the ISFQ. This field is updated in real-time right before a message is delivered to the cloud.

Only OKE or its CWM should include this field in a message.

Store and Forward Sequence Number - _seq

The $._seq field and its value is an integer that identifies a message based on its internal store and forward representation, and differentiates it from other messages.

Only OKE or its CWM should include this field in a message.

Device ID - _src, _dst

Equipment Device IDs

A device ID is string that must remain constant for the OKE system lifetime, be globally unique, and contain information about the type of device.

OKE manufacturers will contact the OKC team at Powerhouse Dynamics to register for a 16-bit Make/Model code. Each 16-bit code is meant for a specific model, when there are more than one model then multiple Make/Model codes must be requested.

The Device ID is then created by encoding the 16-bit Make/Model id as a 4-byte ASCII hexadecimal string in big endian order prefixing a manufacturer specific unique ID.

For example, if the assigned Make/Model is 0x1234 and the manufacturer specific unique ID is the string "ABCDEFGH" then the resulting Device ID string is "1234ABCDEFGH". The total maximum length of the Device ID string is 24. Therefore, manufacturer specific unique ID portion of the string should not exceed 20-bytes. However, it is not necessary and is discouraged to try to make the Device ID longer than necessary since it is included in every OKM which consumes storage space and network bandwidth.

For example, it is not necessary that the manufacturer specific unique ID portion of the string contain make and model information since that is already encoded in the Make/Model identifier. The OKC will be able to map this Device ID to other information such as product Serial Numbers in the cloud so long as the Serial Numbers are reported by the equipment in an OKM field.

An ideal manufacturer unique ID would be one which does not need to be programmed at the factory. For example, some microcontrollers have embedded Ethernet Controllers with associated MAC addresses burned in. Others may have die specific serial numbers, or other serialized data burned in. Using this data eliminates the need for additional process overhead at the factory.

Alternatively, for equipment controllers without microcontroller burned in serialized data, those may opt to use the existing product serial number as the unique portion of the Device ID.

If encoding the manufacturer specific unique ID causes the Device ID string length to exceed 24-bytes then an alternate encoding might be used. For example, encoding a 120-bit manufacturer specific unique ID as a hexadecimal string is 30 bytes, whereas a Base64 encoding is only 20 bytes.

The CWL MJSON interface contains formatters for converting binary data, such as an unique identifier, into a hexadecimal or Base64 encoded string; see %h and %v in the ConnectWare API User's Guide for more details.

OpenKitchen Device ID

The OKC’s device ID will be the string OKC regardless if used as a source or destination. However, normally the OKC device ID will not be present in OKMs since the lack of a source or destination field assumes it is the OKC.

Equipment to CWM Device IDs

Sometimes OKE systems using a CWM will need to send and receive messages pertaining to each other and not the OKC.

For messages between the OKE and the CWM the device ID will use a shorthand notation. The device ID of the OKE will be OKE and the device ID of the CWM will be CWM.

Source - _src

The $._src field is a mandatory field whose value is an array of device ID strings. The $._src field indicates the source of an OpenKitchen message.

When an OKE system sends a message to the OKC it will populate the first array element with its Device ID. If message passes through a CWM before reaching the OKC the module will add its Device ID as the second element of the array. The OKC will be able to determine that the OKE is connected via the CWM.

Every OKM must include this field if the source is not OKC. When this field is not in an OKM then the source is assumed to be OKC.

Destination - _dst

The $._dst field is a mandatory field whose value is an array of device ID strings. The $._dst field indicates the destination of an OpenKitchen message.

Every OKM must include this field if the destination is not OKC. If the field is not included in an OKM then the destination is assumed to be OKC. When the OKC sends a message to an OKE that is connected through a CWM then the first element is the Device ID of the OKE, and the second element is the Device ID of the CWM. Adding the device ID of the CWM allows the IoT gateway to more easily route the message via the MiWi network.

CRC - _crc

The $._crc field is used to verify the integrity of the JSON message. The value of the field is a 4-character hexadecimal string. The CRC is 16-bits.

The CRC is computed once the entire message is constructed including the $._crc field where the value is initially set to 0000. The CRC is then computed over the entire message including the NULL terminator. The ASCII encoded hexadecimal value in big endian byte order is then written to the $._crc value field.

To verify the CRC of a message, the value of $._crc is saved, and the actual CRC is computed over the message after setting the $._crc string value to 0000. If the CRCs match, then the message integrity is good. If not, then the message is discarded since data corruption has likely occurred. An event may be logged indicating a CRC failure.

Every OKM must include this field.

Outbound messages generated by Open Kitchen Equipment (OKE) are queued by the Connectware Module or Network Device (CWM) before being transmitted to the Cloud or Edge Server (OKC).

CWM queuing ensures outbound messages can be delivered with confirmation to the Cloud or Edge Server (OKC) regardless of intermittent network connectivity, or other events that may affect the equipment’s operational state.

When the network connection allows, the queue is emptied in the order the messages were written.

Typically, when network connectivity is good the queue is empty, and messages are delivered to the OKC with minimal delay.

There are two outbound store and forward queues, one is for priority messages and the other is for telemetry.

Likewise, inbound messages from the OKC are queued by the CWM before processing by the OKE.

Queueing ensures inbound messages can be reliably handled regardless of the disparity between the speed of the network connection versus the speed of message processing.

Priority Queue

Any OKM containing a $._rid or a $._pri field is put into the CWM's PSFQ. The PSFQ is always emptied before the TSFQ. This allows certain messages to be processed ahead of telemetry data. Messages in this queue do not need confirmation from the OKC before being removed from the queue.

The PSFQ is sized to hold an entire file transfer containing at least 2MB file of file data.

Telemetry Queue

All non-priority OKMs are put into the TSFQ. Messages in the TSFQ are only removed once they have been confirmed as received by the OKC.

A TSFQ typically can hold up to two to four weeks of equipment telemetry.

Inbound Queue

OKMs inbound from the OKC are put into the ISFQ. Messages are pulled off the ISFQ and processed in order.

The ISFQ is sized to hold an entire file transfer containing at least 2MB of file data.

Payload commands are encapsulated in the $._pld value. A standard payload command is one that is implemented on all OKE platforms.

While it is possible to include multiple payload commands in a single message, the OKC will generally only include one payload command per message. Likewise, it is recommended that OKE only include one payload command per message to maintain message processing simplicity.

Heartbeat - _hbt

The $._pld._hbt field value is an object. An OKE vendor encodes their equipment specific telemetry extensions as the object value.

This field is present in outbound OKE messages. The $._cmd field’s value must be wr.

The OKC may request a heartbeat to be generated at anytime by sending a message with $._pld._hbt set to true and the $._cmd field set to rd. When received the CWM or OKE will immediately generate a heartbeat message.

ConnectWare Version - _cwv

The $_pld._cwv field value is a string of the form "Major.Minor.Build" where each of the fields is an integer.

Uptime - _upt

The $._pld._upt field value is an integer representing the uptime of the OKE since last startup in minutes.

Restart - _rst

After a restart the $._pld._rst field with a Boolean value of true is added once to the first message of the first Heartbeat set by the OKE or its CWM.

Version - _ver

The $._pld._ver field value is an array.

Within the $._pld._ver field array is zero or more arrays. Each of these arrays reports the device type, firmware version, and hardware version of every logical device within the OKE as strings.

Only an OKE and its CWM should include this field and only once in each Heartbeat message set.

Set Time - _time

The $._pld._time field value is an ISO 8601 formatted string, and is only processed when the $._cmd field value is wr. When processed the device will update its internal clock to the new time and use it for all subsequent timestamps.

OKE Implementation

An OKE must only support an ISO 8601 format of "yyyy-mm-ddThh:mm:ss" and this format shall be interpreted as local time. Other ISO 8601 formats may be ignored.

The OKC should not send this command to the OKE. The CWM is responsible for ensuring that the OKE has the correct time by periodically sending this command to the OKE.

CWM Implementation

The SPOD CWM ignores this command. It gets current time from the IoT Gateway in the same manner as other MiWi devices do.

The Sphere WiFi CWM supports this command and will accept the default format of "yyyy-mm-ddThh:mm:ss" however this is not useful or necessary for the Sphere CWM since it is already able to get GMT time from NTP. Therefore, the cloud should use one of the following formats so that the CWM can determine and save the time zone offset. The time zone offset is used by the CWM for two purposes. First it allows the CWM to convert the local time timestamps reported by the OKE into GMT time before sending them to the OKC. Second, it will allow the CWM to report time zone information to the OKE so that the OKE may optionally display the time zone to the user (not yet implemented).

yyyy-mm-ddThh:mm:ssZ - GMT time with 0 offset

yyyy-mm-ddThh:mm:ss+hh:mm - GMT time with positive offset

yyyy-mm-ddThh:mm:ss+hhmm - GMT time with positive offset

yyyy-mm-ddThh:mm:ss+hh - GMT time with positive offset

yyyy-mm-ddThh:mm:ss-hh:mm - GMT time with negative offset

yyyy-mm-ddThh:mm:ss-hhmm - GMT time with negative offset

yyyy-mm-ddThh:mm:ss-hh - GMT time with negative offset

The OKC is responsible for sending this command when the time zone changes, for example during daylight savings, otherwise the GMT timestamps will be wrong.

Ping - _ping

The $._pld._ping field value is a Boolean with a value of true and is only processed when the $._cmd field is rd. When a CWM or OKE receives this command it will respond with a message containing $._pld._ping set to true, $._rid set to the $._id of the incoming message, and $._cmd set to wr. The OKC may use this command to verify that roundtrip communication between the OKC and CWM or OKE is functioning correctly.

Reset - _reset

The $._pld._reset field value is a Boolean with a value of true, and is only processed when the $._cmd field value is wr. When processed the CWM or OKE will perform a soft reset. Only a Serial Data Link Layer acknowledgement is expected from the equipment before it resets.

This field is only present for inbound OKE and CWM messages.

Reset To Defaults - _rtd

The $._pld._rtd field value is a Boolean with a value of true, and is only processed when the $._cmd field value is wr. When processed the CWM will perform a factory Reset to Defaults. The CWM will perform a soft reset as necessary for the new default configuration to take effect.

This field is only present for inbound CWM messages.

Port Configuration

This command is only supported by the CWM, it allows the OKC to manually set the desired port and communication settings for OKE communication, thereby overriding previous settings or ongoing OKE discovery.

The OKC sends a message with $_cmd set to wr, $._pld._oke._port set to usb, ttl, 232, or 485, and $._pld._oke._baud set to an integer value. Baud is ignored when the port is usb.

Queue Flush - _flush

The $._pld._flush field value is a Boolean with a value of true, and is only processed when the $._cmd field value is wr. When processed the CWM will empty the PSFQ, TSFQ, and ISFQ.

This field is only present for inbound CWM messages and is optionally implemented in the OKE.

File and Firmware Transfers

The file transfer command allows large files such as firmware, images, and event logs to be transferred between the OKC and OKE.

File Transfer - _ft

The $._pld._ft field indicates a file transfer operation and its value is an object. The $._cmd field indicates if the transfer is a read or write.

Supporting file transfer does not presume that OKE has a traditional organized file system. Also only reading or writing one file at a time is supported.

Writing

A sequence of one or more messages where the $._cmd field value is wr the $._pld._ft._name, $._pld._ft._off, and $._pld._ft._frg fields are present is a file transfer.

The $._pld._ft._name field value is a string that is the file being written. The maximum length of a name is 16 characters not including NULL termination.

The $._pld._ft._off is a 32-bit signed integer that indicates the byte offset at which the data should be written.

The $._pld._ft._frg field is Base64 encoded binary data that should be written to the file offset.

$._pld._ft._frg will contain between 0 and 512 bytes of binary data. When less than 512 bytes of binary data is received it indicates the end of file. If a file is an exact multiple of 512 bytes then the last $._pld._ft._frg will be an empty string "" to indicate end of file.

$._pld._ft._sz is an optional 32-bit signed integer field that should only be sent when _pld._ft._off is 0 to avoid unnecessary overhead. The value of the field is -1 if the total size of the file being transferred is not known, otherwise it is >=0 and is the total byte size of the file being transferred. The file receiver must not use this field to determine when the file transfer ends.

When a destination receives a $._pld._ft command and the offset is zero, this has the logical effect of opening the file for writing.

When a file is open for writing the destination processing a $._pld._ft command will ignore write requests when fragments are received out of order or are a duplicate.

The destination will also automatically close an open file when end of file is reached or a new file transfer command is received with an offset of zero for a different file.

File Transfer Status - _fts

When a file is open an OKE and CWM will indicate the file transfer status to the OKC. This allows the OKC to continue a partially completed file transfer without starting the transfer over from the beginning.

The $._pld._fts field indicates the status of an open file being written to the OKE and its value is an object. The object contains the $._pld._fts._name field which is the name of the open file as a string, and the $._pld._fts._off field which is the offset of the next file fragment that should be written to the file. If $._pld._fts._off is -1 this indicates an unexpected error has occurred and the file transfer must be restarted.

The OKE and CWM will send an OKM containing the $._pld._fts field via the PSFQ once per minute.

Reading

When the $._cmd field value is rd the $._pld._ft._name field is present.

The $._pld._ft._name field value is a string that is the file to be read.

This read command triggers the destination to write the requested file back to the message source.

If the destination is already reading a file to another destination, then that operation ends and a new file read is started.

File Status

OKE will include status of files, their name, size, and CRC, in their heartbeat. This allows the OKC to determine the state of files on the OKE.

The $._pld._fs field indicates the status of files on the OKE and its value is an array.

Within the $._pld._fs field array is zero or more arrays. Each of these arrays reports the file name. The file name is a string. It is possible that future revisions of the CWL will add additional fields about each file.

When a file write completes the OKE will report the updated file status via the heartbeat and the OKC can determine that the file transfer was successful.

Acting on File Transfers

When a file transfer writes firmware to the OKE system, the OKE system will not immediately install it. The OKE system will wait until it receives a reset command from the OKC. The new firmware will be installed before the application boots up again.

For transfers of other file types, it is up to the vendor to determine if the newly written file will be acted upon automatically or only after a vendor specific command is issued.

File Directory

The OKC may request a file directory from either a CWM or OKE. When received the CWM or OKE will report on all files it supports excluding firmware files which are reported in the $._pld._ver field.

The OKC requests the file directory by sending $._pld._fdir with a value of true and $._cmd with a value of rd. The CWM or OKE will respond a message where $._pld._fdir is an array of files and metadata, $._rid is set to the $._id of the incoming message, and $._cmd is set to wr.

File Erase

The OKC may issue a file erase command to a CWM or OKE. The OKC generates a message containing $._pld._fdel._name where the value is the name of the file to erase, and $._cmd is set to wr. The behavior of the erase command is implementation specific for each platform and each file on each platform. The OKC can determine the result of the delete by subsequently requesting a file directory.

High Performance File Transfer

The file transfer protocol described earlier in this section (legacy file transfer) keeps the bulk file transfer data encapsulated in an OKM from the OKC through to the OKE. This means that file transfer fragments are treated the same as any other OKM simplifying the CWM implementation. However, due to the additional OKM protocol overhead its throughput is unable to match that of a dedicated bulk file transfer protocol, such as FTP or HTTP.

This section describes a bulk file transfer mechanism for Connectware that does not require any changes to OKE implementations. If an OKE implements file transfer it will continue to work regardless of using the legacy file transfer or the optimized file transfer mechanism. Only CWM implementations are aware if the file transfer is optimized or not.

Just like legacy file transfer, only one file transfer may be active at a time in either the inbound and outbound direction.

Inbound High-Performance OKC to OKE/CWM File Transfer

When the OKC sends a file to an OKE (or even when a file is intended for a CWM) instead of generating OKMs with file transfer fragments it will write the following request to the CWM:

$._pld._ft._dst is a string indicating the intended destination device ID of the file. The $._dst field is always the device ID of the CWM.

$._pld._ft._url is a string indicating the file resource to fetch from an HTTP server.

$._pld._ft._name  is the logical filename of the data being transferred, and has the same meaning as in legacy file transfers. If the filename is an empty string “” then no file transfer will be started and any ongoing file transfers to that destination will be immediately cancelled.

$._pld._ft._to  is an optional parameter and is a positive integer that represents a timeout in minutes at which the file transfer will be aborted. The timeout starts as soon as the file transfer request is received by the CWM. When the timeout expires the file transfer operation will end regardless of the OKE receiving none or some file data. If this parameter is not specified, then the default timeout is 1440 minutes.

Upon receiving this request, the CWM will start fetching the file from the provided URL and begin creating and transmitting OKM file fragments (per the legacy file transfer specification) to the intended recipient (either the attached OKE, or the CWM itself.) During the transfer, the CWM will monitor the $._pld._fts to ensure that file reception at the destination is advancing. If it is not advancing, then the CWM will virtually rewind the transfer and start sending OKM fragments at the offset where the transfers stalled.

While the CWM is transferring the file, all normal file transfer status will be sent to the OKC so that it can also monitor the file transfer progress.  All other file transfer management mechanisms, such as file directories work the same way as in the legacy file transfer scenario. Lastly, regular heartbeat data will also continue to be delivered normally during the file transfer.

The CWM can only perform one high performance file transfer at a time. The CWM will track high performance file transfer requests for the OKE and itself separately and perform the transfers sequentially.

Outbound High Performance OKE/CWM to OKC File Transfer

The need for high performance outbound file transfers is not as critical as inbound, so the legacy file transfer mechanism for transfers from the OKE/CWM to the OKC will remain the only mechanism for outbound file uploads to the OKC.

CWM High Performance Status

Both the OKE and CWM will continue to send regular file transfer status messages to the OKC periodically regardless if a legacy file or high performance transfer is in progress. When a CWM supports High Performance file transfer it will additionally send status about the file transfers it is directly managing so the the OKC can understand how the transfer is progressing from the CWM’s point of view.

$_pld._hbt.ft is present in the regular CWM heartbeat only when it supports high performance file transfer. The value of $_pld._hbt.ft is an array containing the status of transfers being managed by the CWM. The array is empty if there are no file transfers in progress or pending. When not an empty array it will contain 1 or 2 elements. Each element is an object type containing the following properties: _dst, _url, _name, _off, and _st. _dst, _url, and _name will match that of the original transfer request. If _name is an empty string “” then it will not be reported in the array. _off will be 0 if the file transfer is pending and not yet started. _off will be -1 when a file transfer completes. Otherwise, _off will indicate the offset that is being fetched from the file server at the time the message is created. _st is an array of integer values for transfer diagnostics. The first array element is the number of connections made to the server, and the second element is the number of rewind events that occurred during the transfer. The third array element is 0 if the file transfer timeout has not been reached, and 1 if the file transfer timeout has been reached. Additional array elements may be added in the future, but the order and meaning of the array elements will not be changed. Again, this CWM file transfer status is in addition to the existing file transfer status messages that are periodically sent from both the OKE and CWM, and specifically for the purpose of understanding the state of the CWM when performing a high-performance file transfer.

Server-side Rewind/offset GET Argument.

File transfers should rarely lose file fragments, however there are some scenarios where the destination misses one or more file fragments. The CWM can recognize this situation and rewind the transfer back to the next expected fragment required by the destination. Since there is no mechanism in an http transfer to rewind, the CWM closes the current connection and reopens a new connection to read the file, and passes a GET argument named offset. When offset is not present the server must return the requested file from offset 0. When the offset argument is present it must send the requested file starting from offset bytes. This is demonstrated in the OKS example implementation.

1.1.9        Scheduling

UPCOMING FEATURE – PRELIMINARY DOCUMENTATION – SUBJECT TO CHANGE

Schedule File

To set an OKE schedule the OKC will write a file named "schedule" to the OKE's CWM. The CWM will report the version and the CRC of the schedule file via the file directory command.

The reported file version is extracted from the "ver" field contained in the schedule file.

The reported CRC is computed over the entire file using the same algorithm as used for OKMs, where the value of the CRC field embedded in the schedule is set to "0000" before computing the CRC.

If the schedule's computed CRC matches the embedded CRC, and the JSON is valid then the CWM will run the schedule, else the schedule will not run.

If the file version is out of date, or the reported CRC does not match the expected value then the OKC should transfer a new schedule file to the CWM.

The OKC may overwrite an existing schedule by sending a new schedule. The OKC may remove the existing schedule by sending a file delete request to the CWM. The OKC may read the schedule file by issuing a file read request.

CWM Schedule Status

The CWL will periodically report the following schedule status:

Schedule is running Wednesday's schedule at minute 721, and 1 timeout has occurred sending scheduled commands to the OKE.

OKE Remote Override Configuration

These commands are sent by the OKC and processed by the OKE to control override states:

Sets a remote override state in an OKE: "_rovrs":[<overrideIdx>, <locallyClearable>]

Clears a remote override state in an OKE: "_rovrc":<overrideIdx>

Clears a local override state in an OKE: "_lovrc":<overrideIdx>

Ex:

"_rovrs":[0, 1]  - Enables remote override 0 and allows local clearing.

"_rovrc":0 – Clears remote override 0

"_lovrc":1 – Clears local override 1, if it is locally clearable.

1.1.9.4         OKE Schedule Status

When an OKE supports overrides it will periodically report the following status message:

isEnabled is 1 if override is in effect, else 0

enabledCnt is incremented each time an override goes into effect.

remotelyClearable is 1 if the OKC can clear the local override, else 0

remoteClearedCnt is incremented each time a _lovrc command is processed regardless if clearing is successful.

locallyClearable is 1 if the OKE can clear the remote override, else 0

localClearedCnt is incremented each time the OKE attempts to clear a remote override regardless if clearing is successful.

Ex: