Blog
Avoiding 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. DO
Consider CONOPS Early
To deliver the most value to your satellite 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
6 Ways to Build a Space System with Operations in Mind
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. 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 satellite 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. 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
Unique development environment for mission-specific flight software
4. DO
Prioritise clarity over optimisation
When developing CubeSat 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
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 satellite software products.
5. DO
Work in functioning increments
You may find it very valuable to adopt the following pattern for satellite 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. 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 satellite 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…
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 satellite software re-use across a wide range of hardware.
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. 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…
Technology
Learn more about GenerationOne Technology
GenerationOne technology is a model-based platform which forms the basis of our unique off-the shelf satellite software products. It brings a wide range of benefits to all aspects of missions, end-to-end and across the full life-cycle.
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 satellite 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…
Case Studies
It’s the results that count
Browse our case studies to learn how we help our clients reach for the stars.
10. DON’T
Don’t underestimate integration
When you start integrating the bits of satellite 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 Space-Ground Software Systems
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.