Protocol:SHIPBridge

From Serious Documentation
Revision as of 05:08, 9 February 2015 by Admin (talk | contribs)
Jump to: navigation, search

What is the SHIPBridge Protocol?

SHIPBridge is a comprehensive proprietary communications protocol coming in SHIP Version 5 Badge SHIPv5.gif with the following high-level capabilities:

  • Extensive physical layer support including UART, SPI, USB Device, and, in the future, Ethernet, WiFi, and Bluetooth
  • Complete data type movement (Boolean, Byte, Short, Integer, Float, String)
  • Prioritized poll or push-on-change per shared variable for flexible bandwidth management
  • Over-the-wire firmware updates for all firmware and GUI files on the SIM
  • Abstracted remote file system access to all file systems on the SIM from an attached device
  • SIM system information and control

A more detailed description of the SHIPBridge protocol protocol is pending release of v5.0.200 when the Bridge Data Class is introduced.

Contact Serious for a copy of the SHIPBridge Architectural Specification under NDA.

SHIPBridge Architectural Overview

The SHIPBridge framework consists of a set of command and response messages, and their associated data payloads that provide the following capabilities.

  • Perform services or actions on the SHIPBridge hosted platform
  • Send or set data in conjunction with various applications executing on the SHIPBridge platform or a host platform

The services could be either a single standalone action or could be a series of actions combined by the host to perform a higher level function. For example, a host may completely upgrade the firmware and GUI on a SIM through a series of actions (via services) including:

  • reading the serial number of the unit
  • based on the serial number, downloading a new SHIPEngine image
  • downloading a new GUI cargo, and,
  • rebooting the unit.

This overview is designed to provide a high-level understanding of the SHIPBridge framework between SHIPBridge and a host, and the services supported.

Host, SIM

The relationship of the host and SHIPBridge, and the component architecture that comprise both environments is shown here.

      • IMAGE***

Note, as shown, command messages can originate from either the host or SHIPBridge. Which domain originates the command message depends on the service class. All command messages are followed with a response message.

Class, Subclass

Class and Subclass are the grouping of similar services implemented in SHIPBridge accessible to the host. The Executive Class is responsible for establishing the communications with a host Executive Session and must be implemented on all SHIPBridge implementations.

Services

Services are the actions or functions that are performed by SHIPBridge on the SIM. Services support 3 levels of access. They are READ only, READ/WRITE (1 or more) or Exclusive. Access levels are specific to each service.

Sessions

Sessions are virtual communications “pipes” that applications on a host use to access a collection of services on the device to perform particular actions, functions or capabilities. A session will only support a single class of services. For example, a host may be connected to a SIM via a USB connection. The host may be running a simple monitor application showing the serial number, model, and health status of the connected SIM. In this case, the host application would establish a “session” over the connection with SHIPBridge. A different host application, perhaps an uploader for new GUIs, might establish a completely different session over the same USB connection. The different sessions allow both the host and device to direct the communications traffic to the correct handlers. The Executive Session which manages these sessions (creation, usage, deletion) is implemented on all hosts.

Message Structure

Each service is accessed via a command message from the initiator and accompanied by a response message from the target. Command and response messages consist of a standard fixed-size header plus an optional variable length payload. Whether the command or response message for a given service contains a payload depends on the particular service. The maximum message size can be negotiated individually for each host Executive session. All sessions spawned by a host Executive session will have the same initial maximum message size. The message size always starts at 64 bytes per message, and can (upon mutual agreement between host and device) be expanded to any power of two from 64 bytes and beyond. This size includes both header and any payload. Large payloads that exceed the size of the message are packetized across multiple messages. At the message level, there is a CRC integrity checking across the entire length of the message, including the header and any applicable payload. The sequence number field allows the host to match command messages with response messages. It is assumed that any encapsulation protocol based on the physical layer handles these issues, and the message format is independent of underlying protocols and hardware. The message structure is shown here:

Each command message from the initiator will have an associated response message from the target.

Header

The header is a fixed sized and standard for all messages. The header is located at the beginning of each message and contains the minimum set of information to identify the target (class) and originator (session), and process the message (length, version, CRC).

Payload

The payload immediately follows the message header and is a variable size. The length of the payload, if any, depends on the command or response message and maximum message size.

Bus, Communication Interfaces

The SHIPBridge protocol is implemented independent of any specific bus or communication interface. In doing so, the SHIPBridge can be supported on SIMs regardless of the available bus or communications capabilities. Anticipated interfaces to be supported are listed below as examples.

  • USB
  • Serial/UART
  • Other future interfaces may include TCP/IP over Ethernet or wireless, SPI, I2C, and more