Blog

How to Optimise Payload Integration

Easy payload interfacing, even for the most unique of missions

 

Each space mission is unique as every spacecraft has its own goals, objectives and reasons for going into space. At the heart of the satellite functionality is the payload, which is highly specific to each particular mission.

Payloads tend to be developed by specialists in their own fields – for example, a communications payload may be developed by an IoT company or a weather monitoring payload may be designed by a company which deals with providing meteorological data. Integrating these payloads into a spacecraft platform, however, remains the task of a satellite developer.

Over the past 10 years we have seen a wide range of payloads and the impact that payload interfacing can have on the mission, its development and operations.

 

What is a satellite payload?

It may be hard to define what exactly a satellite payload is. Essentially, it is the module responsible for performing the main function of the mission, which could be Earth observation, communications or navigation.  It is the heart of the spacecraft and the reason why it exists in the first place.

For example, an Earth observation or a remote sensing satellite may have optics or a radar as its payload. These can be used to monitor the planet for a variety of purposes – e.g. they can observe the changing environment or they can provide evidence of coastal erosion or temperature changes or many other observations that provide users with invaluable data.

Each satellite can have one or multiple payloads, serving different and often unrelated mission goals. Payloads are usually very unique to each mission and are frequently being developed in parallel to the spacecraft platform by a team who probably know their payload technology really well but may not be space specialists.

In addition, the commercialisation of space and standardisation of spacecraft hardware – which can be easily available off-the-shelf – provide a huge amount of flexibility in designing a mission to meet the needs of a payload.

This flexibility, coupled with a lack of specialist mission expertise, can lead to a lot of complexity in the relationship between the payload and the spacecraft platform.

Why is the payload interface important?

 

Since the payload interface is often specified by the payload team, who tend to be non-space specialists, this can often result in somewhat arbitrary design choices and even lead to changes during development. Throw multiple payloads in the mix and you’ll find yourself in deeper trouble than you signed up for!

What’s more, these interface difficulties can impact the mission across its entire lifespan – from the high-level mission specification and design, continuing into hardware and software development all the way through to operations. The relationship between the payload and the platform can have a serious impact on mission development and how effectively the mission operates to achieve its objectives.

Payload interface and protocol

 

A standard payload protocol may seem like an obvious solution to easy and straightforward integration. Aiming for a standard protocol is definitely a good idea, but we’ve seen from experience, that if it is made too restrictive people tend to break it or try and find ways around it. This leads to problems with interpretation of the protocol and communication issues, not just between the payloads and the satellite platform, but also between people in different teams.

It’s a better idea to add more flexibility, such as support for different interfaces. It also makes sense to define one protocol independent of interface technology and map it across interfaces, rather than define a new protocol for each one. Consistency is always the key to success.

However, having on-the-wire compatibility with even the best-defined payload protocol is not enough. More important than bits and bytes is the semantics of the protocol which defines what each part of it means and how they should be used together.

The semantics effectively form the bridge between the protocol and the high-level concept of operations. We have frequently seen mismatches in assumptions about how a payload is to be operated. This often leads to issues of various complexity during both test and on-orbit operations and results in longer development time, higher cost and more risk. That is why the concept of operations for a payload is usually the best place to start the design process, before you proceed to defining interaction semantics or protocols on interfaces.

Having a well thought through payload concept of operations, backed up by standard semantics and protocols is definitely the right way forward to help lower the risk of any mission.

 

Model-Based approach to payload interfacing

 

As we mentioned above, a lot of problems can come from poor communications between teams, with no clear and consistent way of sharing information about how a payload uses the standard protocol.

Perhaps the most valuable thing we have done for improving payload interfacing and management was to define a structured way of gathering all the information about a payload into a single source of truth – a well-defined machine- and human-readable meta-model.

The model captures a great deal of information and some of the most important bits are the specifics of how a service is used by a payload, such as the parameters it has, and all the documentation which goes along with that.

Over the years we have expanded what our model can express to include, at a low level, the ability to specify services themselves, and at a high level, the procedures which can or should be used to operate the payload. We are still relying on the definition of the protocol so the model doesn’t need to capture anything about on-the-wire encoding which would make the model very complex and difficult to use.

Over the past three years, we have been applying this model-based approach to the payload interfacing, and so far, around 10 payloads have been able to benefit from it in terms of easier payload development, integration, test and operations. This, in turn, leads to a significant reduction in development times, risks and costs. It also has a visible impact on the effectiveness and efficiency of mission operations, that we have been involved in.

Real-life mission example

 

The UK Satellite Applications Catapult runs an In-Orbit Demonstration (IOD) programme, which offers space companies a fast-track, low-cost opportunity to test their service or technology on a CubeSat mission launched into low Earth orbit. IOD helps accelerate to ‘proof of concept’ stage by providing an affordable in-orbit testbed and a range of operational and business support services to exploit the commercial potential of the mission.

We have been privileged to support Satellite Applications Catapult’s IOD missions with our space software system, including one of their latest missions, Amber-1, which made full use of our model-based payload interfacing approach to support early development and test.

The mission model, which – amongst other things – defines the payload interfacing, has been passed back and forth between the different teams working on the mission and has been an invaluable single source of truth for the latest payload information.

 

We’ve been our space software technology for the past 10 years through extensive development work on more than 30 spacecraft which are currently using our flight and ground software.

Contact us today to arrange for a free trial or book a demo to learn more about our products and how they can help make your mission a success.