SpaceWire protocol ID: what does it means to you?

Glenn Rakow, Richard Schnurr, Steve Parkes

    Research output: Chapter in Book/Report/Conference proceedingChapter

    4 Citations (Scopus)

    Abstract

    SpaceWire is becoming a popular solution for satellite high-speed data buses, because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of SpaceWire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because SpaceWire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of SpaceWire to define unique packet formats and define how these packets are to be processed. SpaceWire also has two different packet formats that may be presented to the end user, one with a Destination Address and one without. This further complicates the system design, as both options cannot be supported. Each particular mission writes it's own Interface Control Document (ICD) and tailors SpaceWire for it's specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions.

    A new packet format for SpaceWire has been defined as a solution for this problem. This new packet format is on the standardization track and will be documented in a new standard along with protocols developed by the SpaceWire working group that utilize the new packet format (see section 6.1 RMAP). The European Cooperation for Space Standardization (ECSS) will assign the document number ECSS-E-50-11 to this new standard that will compliment the existing SpaceWire standard, ECSS-E-50-12A. This new packet format will support protocol development upon SpaceWire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over SpaceWire.

    The SpaceWire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the SpaceWire.

    The new extended packet format adds one new field to the packet that greatly enhances the capability of SpaceWire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the SpaceWire working group and the protocol description published for others to use.

    The development of Protocols for SpaceWire is currently the area of greatest activity by the SpaceWire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.
    Original languageEnglish
    Title of host publication2006 IEEE Aerospace Conference
    Subtitle of host publicationBig Sky, MT; United States; 4 March 2006 through 11 March 2006
    Place of PublicationPiscataway NJ/US
    PublisherIEEE
    Number of pages7
    Volume2006
    ISBN (Print)9780780395466
    DOIs
    Publication statusPublished - 1 Jan 2006

    Fingerprint

    Dive into the research topics of 'SpaceWire protocol ID: what does it means to you?'. Together they form a unique fingerprint.

    Cite this