SHIPBridge:Architectural Overview

From Serious Documentation
Jump to: navigation, search

See Also


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

  • Perform actions (or services) 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 can be either a single standalone action or 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.

SHIPBridge High Level Architecture

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.


A SHIPBridge Class is a major grouping of similar capabilities, SHIPBridge in v5.0 has the following classes defined:

  • SHIPBridge Executive Class, responsible for establishing communications with a host and required in all SHIPBridge implementations
  • SHIPBridge Processor Class for accessing processor-related capabilities, such as reboots
  • SHIPBridge Platform Class for accessing platform-related capabilities, such as setting/getting the current time/date, getting the SIM's serial number, etc. Within this class is the ability to access files on the platform including fixed and removable media
  • SHIPBridge OS Class for accessing OS-related capabilities, primarily used for Serious debugging, such as the current task list within the firmware
  • SHIPBridge Data Class for exchanging GUI-related control and status data between the host and the GUI running on the SIM.


Within each class is a set of Subclasses of similar Services within the Class.


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 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:

SHIPBridge High Level Message Structure

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


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).


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