Blog

How to Develop Flight Software for Large Satellite Systems

As the New Space market continues to grow, more and more satellite applications require a large number of spacecraft – whether as part of a constellation or an overall programme. These satellites need to be managed and coordinated to work well together and deliver the service to the user.

However, setting it up once is not enough – large space systems are under constant change. Small satellites tend to have a limited life span and need to be regularly replenished. Often, newly added satellites come with different hardware or can even be built by different integrators, which means that they also require new software. Moreover, the satellites that are already flying may also need software updates through maintenance or addition of new capabilities.

As a result, the space system can quickly become very heterogenous and dynamic with constantly changing hardware and software, yet it still needs to be managed as whole.

Challenges

Challenges for flight software development

In order to support high-volume development for large-scale space systems, flight software needs to have a few key features.

Availability

Software needs to be available early in the process for development and testing to support early integration and operations development

Flexibility

Software needs to be highly adaptable to change after launch as requirements may change through updates or addition of new hardware

Rapidity

Timeline for development is typically short and under pressure, so software must be ready quickly

Capability

There is an increasing amount of functionality being shifted from hardware into software, which needs to be supported

Reliability

Software is mission-critical and must be robust with failure risks closely managed and controlled

Scalability

Software needs to be able to scale across the whole flight-ground system, as it grows and develops

Diversity

Even functionally-similar elements may have differences in software

Operability

Software needs to be very easy to operate to deliver the service quickly and efficiently

GenerationOne Technology

 

We tackle the above challenges through our innovative GenerationOne Technology, which we have been developing for the last 10 years. GenerationOne technology is a model-based platform which forms the basis of our unique off-the shelf software products. It supports rapid and cost-effective software development through reusable software components and flexible ways of integrating them together.

 

What is Suitable for Reuse?

 

Many of the above flight software challenges can be addressed through software reuse, but it’s important to determine the size of the units suitable for reuse: this affects how flexible and adaptable the system is and how complex the overall development process can become.

There’s a sliding scale in what can be re-used. On one end, there are large units – e.g. total reuse of one or more applications. Whilst this process is very easy to implement and solves the problem of complexity, it doesn’t offer much flexibility, which is critical for high-volume programmes. On the other end of the scale, there are small units – software elements that can be used to compose applications. This gives a much higher level of flexibility, but it becomes a more difficult process to manage unless you have the right tools.

Our GenerationOne Technology works with small units of reuse, which we call software components, and offers flexible tooling for easy and reliable development.

 

Managing Reuse through Services

 

Managing small units of reuse requires well-defined and well-structured interfaces. Where components interact directly with each other, we use what we call well-defined services.

Service connections can be made statically at build time or dynamically at run time. Services are used to describe interactions between components, including flight-ground interactions. They describe behaviour at a high semantic level, but they do not define any encoding – i.e. they are completely independent of packets or messaging or any other bits of encoding. Within a process, they end up resolving to a very simple function call, whilst out of process they can be mapped onto custom or standard protocols. That allows us to separate what we are trying to represent from how it’s actually being represented. That means that we can abstract the operation of the system away from the underlying messages, packets and hardware systems and offer standard ways of working across a large scale and diverse space system.

Managing Reuse through the Model

 

However, it does mean that there is a lot of information to manage, which can quickly become tedious. And that’s where tooling can really help by making use of the available information to support the overall workflow. We capture this information in the machine-readable format and it builds the basis of our underlying model. We then provide it to tools, which helps speed up the development flow, increase developer efficiency, reduce scope of errors, define configuration and maintain documentation.

The model is focussed on capturing the functional architecture of the system both in terms of services and in terms of components. It covers the complete system – both flight and ground sides, even if it includes multiple spacecraft. It allows you to see the larger picture and the entire system.

The model can be used across the complete development life-cycle – you can start with prototyping and develop a model that is quite sketchy and only defines a few things, but then it can progress to the development process and eventually to operations. The model also makes it easy to identify functional similarities and differences in the system, even if they happen over time, e.g. in constellations with different generations of spacecraft and different capabilities.

Challenges

Challenges for flight software development

With that in mind, take another look at the key challenges to see how GenerationOne helps to support high-volume flight software development.

Availability

The component-based architecture facilitates early software development – you can quickly put together a starting point for your mission using the existing library of components.

Flexibility

Having components as small units of reuse increases flexibility and adaptability as you are able to substitute very small units of functionality in and out. This helps get a lot of flexibility and remain adaptable to change.

Rapidity

Component-based reuse helps facilitate rapid development and the model helps reduce test and ground software configuration time.

Capability

Service-oriented approach helps to manage the complexity associate with a very capable system.

Reliability

Components support reuse of flight proven code and tests can be held in libraries alongside component types. That allows us to achieve high degree of confidence in the code that we are working with.

Scalability

Model can easily be scaled to large constellations (including those developing over time – such as programmes or high volume manufacturing), whilst services help provide consistency.

Diversity

Model helps identify (dis)similar parts of the system, whilst services provide uniformity of semantics independent of implementation.

Operability

Services provide consistent and well-defined semantics for operations, that’s abstracted from the underlying hardware, which is also a good starting point for automations of operations.

Case Study: GenerationOne in a multi-spacecraft system

 

 Faraday Phoenix satellite, developed by In-Space Missions

 

GenerationOne Technology have supported a number of high-volume missions and projects. One recent example is the Faraday service, which is a hosted payload service, developed by In-Space Missions, with frequent scheduled flights and rapid time to flight for payloads. The first of the constellation, Faraday Phoenix, is in orbit at the moment and there are further launches scheduled.

A lot of effort has gone into creating a very flexible and scalable hardware architecture for the Faraday programme, and the software architecture – which has been designed to match that – is making full use of the component-based GenerationOne approach.

Although the spacecraft platform can be similar and is shared between multiple payloads, every satellite is different and the combination of payloads for each satellite is unique. What’s more, some customers have payloads on multiple satellites. That means that the Faraday spacecraft need to be managed both individually and as a constellation.

GenerationOne is used on both flight and operations software for the Faraday programme. The component-based modularity has been critical to managing its diversity, whilst the services have been critical in helping to define things like the standard payload interface, which allows us to do “fast-track” onboarding of payloads. And finally, the underlying model helps capture complete and diverse system and enables multi-satellite operations.

 

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

Contact us today to arrange for a free trial or book a demo to learn more about our GenerationOne technology and how it can help make your constellation or space programme a success.