Blog

10 Ways to Avoid Common Pitfalls in Space Software Development

Over the past 10 years we have gained an impressive amount of experience building a good number of diverse satellite missions. To mark our 10th anniversary, we have compiled a list of common “Dos” and “Don’ts” that we often come across in the development process.

Download the full list of the “Dos” and “Don’ts” of mission software development.

1

1. DO

Consider CONOPS Early

To deliver the most value to your mission, decisions around the concept of operations need to drive the design. It is important to understand in practical terms how the interface is going to be used from the operational point of view. If you fail to define that, you risk developing a package that technically works as intended but is really difficult for operators to use or is very expensive and very impractical.

ALSO READ…


Blog

Operations-Led Space Software Development

Space system developers see flight software as separate and independent from its ground counterpart. Consider an alternative approach that focusses on what you are trying to achieve for your mission rather than how it is implemented.


Product

Mission Control Software

Easy-to-use monitoring and control of onboard changes during development and flight

2

2. DO

Influence Hardware Decisions

Depending on the context in which you are operating, take every possible opportunity to influence the design of the hardware and the interfaces. That is the part of the system where things can easily go wrong. Whilst all the parts of your mission may technically meet your defined requirements, you may easily end up compromising the overall system performance because of the interface technology you’ve chosen, or the signals you do/don’t have available or the design of the protocol.

ALSO READ…


Blog

Say No to Vendor Lock-In: Benefits of an Open and Modular Software System

As a service provider, you may want to take advantage of price competition between hardware manufacturers and make your constellations heterogeneous, comprising satellites from different manufacturers with different capabilities. Learn more about avoiding vendor lock-in.

3

3. DO

Use Consistent Terminology

Avoid inconsistent terms, as they can lead to major errors. For example, you may see SPIs referred to as 0-1-2-3 in some places but a-b-c-d in others. There is an implicit conversion between them but it’s not documented. Software terminology (e.g. parameter, configuration, task) can often be used very loosely, but it should have a very precise meaning. It is critical to be very strict with maintaining consistency of your terms.

ALSO READ…


Product

Flight Software Development Kit

Unique development environment for mission-specific flight software

4

4. DO

Prioritise clarity over optimisation

When developing software, it is important to ensure that it can be understood by others, both on the architectural level of the design of the interfaces and right down to the source code itself. This is especially true if development is to be shared between several team members or extended over a long period of time. It may be tempting, especially when dealing with resource constraints, to worry about optimisation too early and compromise the clarity of the system. Only introduce optimisation when you have evidence of performance problems and address those without compromising the overall integrity of your design.

ALSO READ…


solutions

Solutions

Find the right solution for YOUR mission

Whatever your satellite project, we’ve got the solutions to help you simplify and optimise your space mission through our innovative software products.

5

5. DO

Work in functioning increments

You may find it very valuable to adopt the following pattern for space software development: 1.build-integrate-test in little chunks 2. repeat 3.do this as a fully visible part of the development process. This approach will allow you to demonstrate progress and deliver value as early as possible into the project, reduce integration risks from the start and build confidence in requirements to ensure you’re developing the right software for your mission.

ALSO READ…


Blog

Distributed Systems, Distributed Design

A distributed systems approach can be an effective tool in software development for space missions. Find out what it is and how it impacts the development and operations of a space system.

6

6. DON’T

Don’t over-generalise solutions

Resist the temptation to build something that can be re-used in every possible context you can imagine, especially if the software is meant to be re-usable. It can be a dangerous trap which will waste a lot of your time and effort on something that may never be used again. Additionally, it adds risks into the project that you may appear to cover in different use cases, but they are not fully tested. You need to put sensible limitations on the generality of the solution you’re developing and keep the focus on the needs of your particular mission.

ALSO READ…


danial-ricaros-FCHlYvR5gJI-unsplash

Webinar Recording

Enabling portability across diverse hardware with a model-based approach

Watch our CEO talk about how we use the model-based approach to tackle the problem of software re-use across a wide range of software.

7

7. DON’T

Don’t under-generalise solutions

On the other hand, it’s a bit of a balancing act here. If you do the bare minimum to get the task done without taking a step back to think about putting different abstractions in place and considering the overall architecture, you’re likely to end up with something that is difficult or even impossible to maintain. Inevitably, your requirements change and something that is very specialised is going to be quite hard to manage.

ALSO READ…


Blog

More Than Just CubeSats: Model-Based Software Engineering in Space

Model-based approach based on components means the platform can be easily adapted to any system that is suited to model-based software engineering. This could be small satellites, robotics, automated space systems, and much more.

8

8. DON’T

Don’t design “super managers”

When you’ve developed an architecture with a number of different modules in it, you may resist the introduction of a new element because of the workload it involves. But that is a risky strategy. If you have some functionality that you are unsure what to do with, you may end up lumping it into something that is vaguely related. For example, if you have a payload manager component, anything remotely related to the payload may end up added in here. If you’re not careful about what you’re doing, this may result in developing unmaintainable super functionality, which can compromise the integrity of your design and coherent functionality of your modules. It’s always good to step back and think about re-visiting your architecture.

ALSO READ…


Gen1__

Technology

Learn more about GenerationOne Technology

GenerationOne technology is a model-based platform which forms the basis of our unique off-the shelf software products. It brings a wide range of benefits to all aspects of missions, end-to-end and across the full life-cycle.


Product

Flight Software Development Kit

Unique development environment for mission-specific flight software

9

9. DON’T

Don’t be lazy with requirements

Your project requirements may often be incomplete, and you may be reluctant push back on them. However, there really has to be a good specification of the software, agreed with everybody within the project team. Otherwise, it’s easy to end up with something that does not actually meet the expectations of your mission. The specification does not need to be in the traditional format of documenting requirements. Depending on the mission, it could be in the form of user stories or other formats, but it is vital to have a written agreed specification that everybody can easily access.

ALSO READ…


Launched Missions

Our Hall of Fame

See the full list of the missions we worked on.


Case Studies

It’s the results that count

Browse our case studies to learn how we help our clients reach for the stars.

10

10. DON’T

Don’t underestimate integration

When you start integrating the bits of software together on the actual hardware, it is important to recognise in the project plan and across the mission team that the integration may not work the first time round. There are always going to be incompatibilities and things you haven’t thought of before. It is highly likely that you will discover new problems when you see the whole system working together in more realistic conditions. It is important to have a recognition of that in your plans and give it space to iterate and get it right.

ALSO READ…


Blog

Benefits of Integrated Flight-Ground Software Development

The ground and space segments of a satellite project are often developed independently of each other and at different life cycles of the mission. Find out about an alternative model-based approach which support for quick and easy integration of flight and ground segments.

Think we can help? Give us a ring or drop us an email, we are here to help. Contact us today to discuss your satellite software needs.