Episode 46 of the Space Industry podcast is a conversation with Peter Mendham, CEO of satsearch member Bright Ascension, about space software development.
Episode show notes
Bright Ascension is a Scotland-based software company that builds tools, model-based platforms, and solutions for space engineers and other stakeholders. In the podcast we discuss:
- Typical timelines for software development in different types of space mission
- The common bottlenecks that slow down development and how to mitigate them
- The risks that ineffective software can bring to missions and services
- How to streamline software and communication across different areas of engineering
Bright Ascension’s space portfolio
The Bright Ascension Mission Control Software (MCS) is designed to monitor and control onboard changes of the space mission. It harnesses the power of automation as well as unattended operations and further improves the efficiency and scalability of the mission. The MCS provides an ecosystem for parameter and event monitoring, including telemetry visualization, archiving, and monitoring with alarms and condition notifications.
The Bright Ascension Flight Software Development Kit (FSDK) is designed to create mission-specific flight software using configurable and pre-validated components. The FSDK component library includes a wide range of components covering all mission needs and it is built on a variety of standard/cross-platform technologies, which can be readily adapted to suit different processes.
Please note that while we have endeavoured to produce a transcript that matches the audio as closely as possible, there may be slight differences in the text below. If you would like anything in this transcript clarified, or have any other questions or comments, please contact us today.
Hywel: Hello everybody. I’m your host Hywel Curtis. And I’d like to welcome you to the Space Industry by satsearch, where we share stories about the companies taking us into orbit. In this podcast, we delve into the opinions and expertise of the people behind the commercial space organizations of today who could become the household names of tomorrow.
Before we get started with the episode, remember, you can find out more information about the suppliers, products, and innovations that are mentioned in this discussion on the global marketplace for space at satsearch.com.
Hello everybody and welcome to today’s episode of the Space Industry Podcast. I’m joined today by Peter Mendham, the CEO of Bright Ascension.
Bright Ascension is a space software development company based in Scotland in the UK. And today we’re going to talk a little bit about sort of alternative approaches, approaches to building space software infrastructure, sort of the things that companies need to be thinking about in the industry today as we are seeing so many new innovations and ideas come online and become possible in today’s industry.
So Peter, thank you very much for being available and spending time with us here today. Is there anything, firstly, that you would like to add to that introduction?
Peter: No, it’s great to be here Hywel. Thanks for the introduction. I think it is maybe worth mentioning that we started the company about 11 years ago now with quite a focus on developing software for the space industry and over that period of time we’ve spotted the opportunity to create products to really empower people to develop space software themselves.
And so now what we do is a mixture of those two things; helping people do things themselves, helping them with that, but also supporting them with the benefit of our experience and expertise along the way.
Hywel: Brilliant. Thank you. So that kind of leads into my first question there. Talking about this experience that you do have as a company.
I think, we’re always worried in the space industry about the mission timings, which is the case for every aspect of development and it, it may be a little bit of a how long is a piece of string question, but I was wondering, to begin with, if you could give us an idea of how long it can take to develop a sort of typical space software system or an application today, one that will cover both the space and the ground requirements?
Yeah. Maybe you can discuss some typical timelines for different sort of common types of missions and yeah, give the audience an indication of what we’re working with.
Peter: Sure I’ll do my best. It is a bit of a piece of string situation, but I’d say that it’s actually quite interesting in a more, there’s a more complicated answer to that question that I think is a bit more interesting, which is that it’s not just about a kind of a shrinking of development times.
It’s also about what the way that development is structured and the way that the problem is typically being explored. I think. The short answer to the question is really that although we, when we started out, we were really looking months as a very typical development period and coming from a background that would probably be characterized as more old space, that was certainly seemed as very short.
But I think the pressure is really now on to be looking at kind of six to nine month development periods. But that doesn’t tell the whole story because what we are looking at during that period that makes it harder and more complicated is that there’s a lot of moving pieces. There’s a lot going on at once.
The things like payload development, things like the aspects of delivering the actual service, whether it be earth observation or a communication service or technology demonstration, those will be being developed at the same time as the mission. And that means that the understanding, the shared understanding, and therefore the requirements is gradually evolving during that period.
And so it’s really a process where everything is changing. So some of that pressure means that it’s natural to adopt a more iterative development than has typically been the case in the past, and also to shift what’s done to post launch. And so it’s really about managing a constant process of change where that change is impacting both the flight side and the ground side & when I say ground side, not just the the day-to-day necessity to communicate with a space segment, but also the other aspect of operating a space system and then delivering a service using that space system. So getting all those different elements to, we all evolve together. And to manage the challenges of the kind of constant change and an evolution to try and improve efficiency across the life cycle is a really big driver for why we take the technological approaches that we do.
Particularly we take a model-based approach to how the software is built. Runs, and that’s why we do that. So we’ve got a lot of information captured that allows you to manage that change across that. So that means in some ways that the, perhaps the development period, if you look at it as a whole kind of, to come back to your original question is at least as long used to be and we’re still talking 18 months to two years. It’s just that the time to market is shorter. The time to first results is shorter, and so we are pushing more of the development period to be post-launch or post-mission and things like that, and we’re seeing a lot more, a lot of folk embracing the need for a certain amount of continuous improvement and continuous change.
Hywel: Brilliant. Yeah, that definitely ties in with a number of trends we see in the industry with more versatile and software defined systems and things. And so it, it definitely makes sense that the software development timeline would be, would scale with the complexity of the mission and would, it’s very interesting to, to hear how much or the aspects of it can be shifted to post-launch and in many ways, that makes a lot of logical sense because you need to, you need certain elements of the telemetry and you need to know what data you are going to be actually collecting in space in order to inform, I’m guessing, aspects of the software development.
So that’s great. Thank you. And you mentioned a number of areas that are important to factor in and that have an impact on the software development, payload development time, and the rest of the hardware development. And I was wondering what the common bottlenecks can be in space software development, which can impact the success of the space missions, whether they come from those externals or whether they are just internal fundamental aspects of space software development in general, and how could such issues be resolved?
Peter: I think a lot of the major concerns with the development, and particularly the main things that will impact the overall success. And I suppose if we’re looking at an iterative development, we need to look at both the success of each particular iteration, but also some kind of end goal of some kind. The largest influence that we see, as commonly occurring across different mission types and situations is when there is not really enough focus on the larger picture and when engineering developments particularly say within the spacecraft or parts of the spacecraft even, or particular element of the ground segment are siloed and treated in isolation. And I think that this means that there’s a, there’s a real kind of shoring up of some quite significant risks which end up being deferred until later in the process.
And those risks typically result in significant changes having to be made late in the development. Probably if we are talking about the kinds of things you were particularly stressing, software defined systems, which is absolutely a core part of where we are now is that we; the kinds of risks that that may get left until later by not taking a large picture approach is that those risks could be at the kind of architectural level, the level where significant engineering effort, redevelopment, refactoring, is necessary to address that risk.
So I think not particularly. Taking an operations-led frame of mind when you are looking at the overall infrastructure and taking a focus on the kind of engineering aspects that allow you to manage change and allow you to manage things like scalability and efficiency of operations, the ability to work with diverse and heterogeneous systems, particularly in the context of constellations that allows you to manage the high level kind of architectural risks right from the beginning.
And then to be able to hopefully mean that as the iteration goes on across the development of the system, that the issues that come up are at a smaller scale, and that you are always focused on the end goals of how everything work together? How are we going to deliver the overall service from this constellation?
Say, are we taking a focus to the whole problem, which is about the total cost of ownership in commercial terms, even for a science mission. I think it’s worth putting it in those terms and that’s, again, it’s at the root of the technological approach we take with a kind of model-based approach. And we also use a kind of, service oriented approach to help split the problem up and structure it.
We have a very strong architecture and this hasn’t come out nowhere. I would say that this has over time just from experience. It’s not like we, we suddenly, we had a eureka moment to left out the bath and, and created a new kind of way of doing space software. It’s, it’s better experience and it’s allowed us to create these tools and ways of working over time.
Hywel: Brilliant. Yeah. I think makes perfect sense of the focus on, like you said, on the commercial side of things, total cost of ownership and the holistic approach to the value generation at, on a commercial level, at the end of the operational cycle from the very beginning is necessary to, yeah, answer these architectural problems and adapt to changing conditions and things.
But you used the word risk, quite a lot in that answer, and I think that’s very important. We talk about risks at all sorts of levels on the podcast with different tech companies. So in, in your view, and as you mentioned, the system has not come from nowhere. It’s come from experience with different missions and different engineering projects.
So I wondered if you could share some of the highest risk or even highest cost kind of pitfalls or even errors that engineers need to really look out for when developing their missions.
Peter: Yeah, I think this is an exciting question cause it’s quite broad and I think there are a lot of places that things can come from.
I think that in practice, If I look back at experience of what we’ve been through as a team and the folk who we’ve had the fortune to help along the way, getting their missions up and successful. The places we’ve seen issues, the common element in some ways is how subtle that is, and particularly around things like a selection onboard the spacecraft or selection of a particular supporting service on the ground, such as a ground station network or hosting service or something like that.
Connecting the technical details of that particular sale, let’s say hardware subsystem to the big picture that we were just talking about is where the pitfalls are and underestimating the extent to which there could be something really significant, and I think this is why I was harping on, you picked up on it very well, harping on about risk, is that I think, a way of viewing this is through the lens of risk and to look at how much residual, technical, or otherwise risk is left in your analysis. So if you’ve read commercial sales summary of a hardware subsystem and it seems to do the job, you’ve retired some risk, but not all of it.
To pick a very concrete example during the analysis for a specific mission, a little while ago, we eventually got into the detail of analyzing the low level protocol, which was being created by the, by a particular payload and the payload was being, was generating data which was getting down linked, and the payload hadn’t originally been specified for direct downlink of data, which meant the protocol wasn’t specifically defined for that purpose and it was missing useful field.
And when we propagated, that propagated the impact of the fact that it was missing this field in the protocol, it turned out that made it harder to be sure that we got all the data and when we worked out how, what the impact that was going to have on the number of contacts, satellite contacts that it took to get the data down.
We found that we weren’t able to meet the mission requirements. We weren’t then able to meet the service requirements for delivering data to the end customer. And so for the want of a nail, for the want of, for the want of a field within the particular protocol, there were some really significant implications of that.
Now, that’s a really super extreme example, which is why I picked on it, but I think that’s where the pitfalls are of trying to retire those sorts of risks that connect the small scale to the big scale, and that have those big impacts. And some of them are unavoidable. All you can do is take a risk driven initiative approach to that, I think, and to try and build in enough flexibility into the way that you are approaching, particularly your software.
You come back again to software defined systems. There is an opportunity there. To allow software to absorb some of the flexibility that you need in your system as long as you are capable of managing that change as part of the kind of normal operating procedure of your system.
Hywel: Excellent. Yeah, that’s a really great example. Thank you. It, as you say, for want of a nail, I think back to a high level overview, the architecture and the service level that you’re trying to provide and the real systems thinking, the engineering is so important to balancing these things and yeah, we discuss it and we’ve seen it time and time again, and I think, yeah, the nuances of how the individual subsystems connect to the overall system and deliver the service that’s required in operation is is vital.
So just to follow on that a little bit, are there cases, I don’t know whether the case, you’ve, the main case you’ve discussed qualifies for this. Please correct me if I’m wrong, but I wonder, I was wondering if there were cases where you’ve seen software as being the main cause of a mission failure and how maybe you could explain how the team could have avoided that issue. If you are aware of any, that is.
Peter: I think software issues of one kind or another are inevitable to a certain extent, especially if you are taking an iterative type approach to development. I think it’s a natural part of that. So part of the flexibility that is needed is to be able to assure enough of the software that you don’t see mission loss or significant degradation and mission performance to the point where it’s not going to deliver on the mission needs? I, I think we, yeah, I think in practice in terms of software being the cause of a mission failure. I think in practice, from our experience anyway, it’s never that simple, particularly in the situation where increasingly you’ve got commodification of hardware elements, particularly on board the spacecraft.
So the element of the overall system, which needs to be mission specific because everything else is off the shelf, is the software. And so it’s typically about the contract between the software and the underlying, and I think. there’s a few, there’s a few areas that I think we’re picking up on. One of them is semi apocryphal, which I apologize for, but there’s certainly, in the early days of CubeSats there, there used to be a lot of sharing of information and experience within the community, particularly when it was less commercial than it is now and there was a great series of papers on looking at causes of mission loss in CubeSat, and there was a frequently reported set of failures that were around deployables and they were reported as being entirely kind of hardware issues because it was about deployables not working, deployable antennas or deployable solar arrays being the main ones that folk were focusing on.
And talking to people though within the community and actually asking them about these, I think in most cases it looks like there could well have been a software dimension to this in that if the, if the deployable has particular kind of weaknesses in terms of the temperatures it’s deployed at or whether or not the state of the battery needs to be and the power state of the spacecraft needs to be in a certain way, then were those, or weren’t those built into the software algorithm, which was responsible for activating the deployable?
And we have worked with folk on both sides of that, where folk have done everything they can to try and make the deployable work under absolutely low conditions. And then a bit adamant that the algorithm needs to be incredibly simple. You just press go and that’s it. Alternatively, we’ve worked with folk who have incredibly, carefully characterized every aspect of that deployable and landed us with an algorithm that is hugely complicated. But on the other hand, it’s, I guess in some ways back to risk. It’s a, it’s then a well-characterized and retired risk cause it’s been so thoroughly investigated.
I think in terms of examples of near mission failure, the first ever spacecraft we worked on in this sort of, nearly 35, I think spacecraft now flying our software and the first one was in 2014. It was the UK Space Agency’s first CubeSat. And a lot of the people involved were doing things for the first time and there were issues on board, which were their root cause were hardware issues, but, it was, the mission implications came from what software did with them.
And I would say that this is, we see the most common is there might be some kind of root hardware cause, but there’s no reason why that couldn’t be handled in software. But for whatever reason, it’s not so perhaps no one knew about it or it’s behaving in an undocumented way or that kind of thing. And in this case, it was a case of the software.
We never saw the issues on ground. It behaved very different in flight, and so the key to addressing them was flexibility in the software and being able to adapt and having a very clear baseline for what the core trusted part of the software was. As long as we could continue to talk to the satellite, as long as we had the mechanisms for updating software in a robust way.
And in this case, we uploaded some new onboard scripts to the spacecraft and that allowed us to work around the problem. And that kind of flexibility, I think, and reliability in the core elements is essential for coping with all a really wide range of potential issues.
Hywel: Yeah, absolutely. And I think we are seeing, we’re seeing now in the industry and in the discussions that people are having now, because you picked on the example of, or picked the example of, deployables. I think that’s a really key area where these issues can very clearly manifest. But at the same time, without, as you’ve mentioned, a flexible system for communicating with the satellite and adapting to how the satellite is behaving. It’s never a hundred percent clear what the possible issues of the problem is.
Maybe the issue is with the sensor, the system, the solar array may have deployed, but the sensors that are in charge of informing the ground control, controller, is faulty, in which case, as far as you, you get a no power.
Or maybe it’s, if it’s a solar array, there, may be an issue with power collection and you have no other way of sensing or determining deployment aside from how much power is being collected, but the wire’s broken; you collecting no power and you think, okay, well the solar panel hasn’t deployed, and there’s these issues are complex when you can’t see a satellite in operation and you have to adapt to it in different ways. I think that’s really interesting, thank you.
To go back to the way that I introduced the discussion, so we’ve got, we’ve been through typical timelines of space development and the bottlenecks and the risks and pitfalls that are there and the how software can adapt so that it’s, it is not necessarily going to be a weakness, but a strength, not a weakness, it’s a slash bit of the system, but how it can avoid being an area of risk and reduce areas of risk on the rest of the hardware.
So with all these things in mind, you mentioned iterative development and the way that the, you’ve seen systems being worked, but have you got any other thoughts or insights on how space software should be developed in order to work seamlessly, you know, across a IOP operational use and with the downstream downlink service delivery, which is the ultimate goal, essentially?
Peter: I think that our, certainly our main focus at the moment from having, from having really useful discussions with customers about, particularly focusing on the total cost of ownership, which we were talking about earlier. I think it, it is fragmentation in that overall solution. that is a major cause of inefficiency.
When you do look at the bigger, very much, the bigger picture over the long run, and we’re, we are really seeing solutions that, that do tend to be disjointed and inefficient because of that, and there’s two dimensions to this. One of them is the end-to-end system, which I think is part of what you’re talking about.
So the system that goes from say, the space segment and perhaps a payload in the space segment through the, the space platform to, to the beginnings of the ground segment through, through ground stations and such, like through to operations, payload, operations, service management and service delivery to, to the downstream.
So that’s one dimension of the problem is that end-to-end nature of this. And I think you can easily see how fragmentation within that and any part of that being disjointed or managed very differently is likely to lead to inefficiency. And we, and most systems we see really relying on a certain amount of ad hoc and mission specific glue in some of that to keep it all together and maintaining that is, is often a significant challenge.
But there is another dimension to this, which I would say is orthogonal, which is another aspect of that you picked up on though in your question, which is looking at this system over time and even without iterative development, which I would say is increasingly the norm within a large scale space systems, they’re looking at things from even small constellations to large constellations.
There’s going to be constant replenishment satellites in a nano satellite constellation certainly. Each of those replenishments is an opportunity to do something differently. And then we’ve also talked about software updates and software defined systems. And all of those are an opportunity to do things differently or improve, which means that system development is an ongoing activity that is constantly taking place throughout the life of the system. So I would suggest that’s a kind of orthogonal dimension if you’d like to the end-to-end system. You’ve also got the kind of life cycle and the way that goes together, yeah. You were picking up in your question about about, about whether or not there are inefficiencies there, and I think within that life cycle, again, you’re right.
There are, we see issues in how well the life cycle integrates together. So how well does the requirements capture, integrate with design, integrate with development, with test, and then commissioning and so on, across that life cycle? Um, but then also how well does that sit within the context of a gradually evolving system.
When you superimpose that with a life cycle of, say, a single new software update for the flight system, when you superimpose that times over and over for all of the things that are happening in your system, that’s where those two dimensions come together and you end up with a two dimensional problem of both the end-to-end issues and kind of the ongoing development because this is frequently underestimated part of the system and only becomes clear as a, as something which impacts total current cost of ownership over a longer period of time.
That’s why we’ve tried to make it the focus of our, of at least our current developments and improvements to our core products and services, is to try and take into account all the challenges we’ve seen in both of these dimensions and to look at ways of helping people manage the complexities of both of those dimensions. Again, through things like model based aspects and taking a component based approach to software and taking a service oriented approach to the overall system architecture.
Hywel: That’s really interesting. Thank you. So that was a really interesting answer. I do really like the framework, the orthogonal case that you discussed, where you’re looking at the entire evolving system over time. If you consider comparing just in one area, the delivery of broadband connectivity, for example, on the ground versus from on the ground, broad cables versus from satellites, the system, there’s no reason why the system can’t addressed in the same way on the ground, you’ve got a series of optical fibers that gradually need upgrading, and I’m fixing and updating.
You have people’s modems and that they’re using to access whatever it is, certain websites and to run their accounts. And the same is true of, of a satellite delivered broadband service, where over time you want to upgrade the system.
As you said, every change you make to the system is an opportunity to do things differently, to improve and you obviously you also have actual operational data on which to base those improvements when you take a system approach. Really interesting. Thank you. I think just finally, Peter, I wonder, and I think this is where we can wrap up, because I think you’ve shared a whole load of really useful information for everybody to understand how space offer infrastructure can and should be built today.
And so I wondered if there was just anything else that you think sort of mission and service developers need to consider on the software side during their own development and indeed in, in the design of a new mission or service, or an upgrade to a mission or service that they’re running? I wonder if there are any other insights you’d share or anything you haven’t touched on yet that might be interesting?
Peter: Maybe. Maybe it’s a bit a little bit random, but I would say that we’ve taken a very technical focus in the discussions that we’ve had so far. But engineering and especially software engineering, I would say is a human problem as well as the technical one. And when we are working with software, which obviously you can’t grab hold of and you can’t show it to somebody, the way that folk in a team communicate about that in terms of not just the engineering, but the wider teams around actually getting this system to work well in terms of delivering its service.
How well those teams talk to each other can be, make or break for how well that system is built and how well it fulfills its objectives. And so I think the human side of this is easily underestimated, and so exchange of information is really important.
And that’s why we gain from experience, have added more human aspects to our model-based approach in terms of capturing things like documentation and facilitating the exchange of information, but also having really clear workflows that provide a really clear way of managing the development process, the management of change, things like that, and which build kind of human collaboration into that process right from the beginning so that both the technical and human aspect of this system or service that we’re trying to build really mesh together well.
And that’s when we can see the most success out of these kinds of systems.
Hywel: Brilliant. I think that’s, yeah, a great place to wrap up, Peter. The human communication side of development of any aspect of a space mission or space service is vitally important. And you’ve mentioned how Bright Ascension is focused on really ensuring that the tools for doing so are, are built and used and are understood and the workflows and all that sort of things.
But the other aspect of that is obviously, of course, education. People understand what they’re talking about and how to discuss these problems and these opportunities with each other, and I think hopefully, the insights that you’ve shared today helps them to do that with the understanding the possibilities that exist in software development for satellites in the modern space industry.
So yeah, on behalf of the Space Industry podcast that our listeners out there, Peter, thank you very much for spending time with us and sharing these insights and these experiences that you’ve had and how you are approaching this area of the industry at Bright Ascension.
Peter: Thanks, Hywel. It’s great to speak to you.
Fantastic. Thank you. And to all our listeners, thank you very much too for spending time with us today. We are really grateful and you can find out more about Bright Ascension and the topics that we’ve discussed in today’s podcast on the company’s website and the SAT search platform. We’ll have links in the show notes and, if there’s anything that you would like to, any questions you would like to ask the company regarding your own missions and services and your own, the procurement, or the development and design of the missions that you might be building tomorrow, please do feel free to reach out to us a and to Bright Ascension and we will, we would love to hear from you. And yeah, thank you very much and all the best.
Thank you for listening to this episode of the Space Industry by satsearch. I hope you enjoyed today’s story about one of the companies taking us into orbit. We’ll be back soon with more in-depth behind-the-scenes insights from private space businesses.
In the meantime, you can go to satsearch.com for more information on the space industry today, or find us on social media if you have any questions or comments. Stay up to date. Please subscribe to our weekly newsletter and you can also get each podcast on demand on iTunes, Spotify, the Google play store, or whichever podcast service you typically use.