Solving integration and operational challenges for shared and dedicated satellite missions – with EnduroSat

Episode 24 of the Space Industry podcast is a discussion with Viktor Danchev, Chief Technology Officer at satsearch member EnduroSat about interface planning, testing, integration, and other challenges faced in the development of a satellite mission.

Contents

• Episode show notes
• EnduroSat’s portfolio
• Transcript

---

Episode show notes

EnduroSat is a nanosatellite manufacturer and operator with headquarters in Bulgaria.

EnduroSat has built a strong brand in the space sector since being founded in 2015 and has worked with customers all across the globe. In the show we discuss:

• The pros and cons of the standardization of satellite sub-system interfaces
• How teams can work better with satellite platform providers remotely
• The ways that equipment tests (such as hardware and software in the loop) can be run between collaborating teams
• How proprietary technologies and data can be protected in shared missions

---

The portfolio of EnduroSat

---

Episode transcript

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, and welcome to the episode today. I’m joined by Victor Danchev, Chief Technology Officer at satsearch member EnduroSat. EnduroSat is a nanosatellite manufacturer and operator with headquarters in Bulgaria.

The company has quickly built quite a strong brand in the space sector since being founded in 2015 and has worked with customers all around the world. Today, we’re going to talk a little bit about how to solve some of the common integration and operational challenges for shared and dedicated satellite missions.

But first Victor. Hello and welcome to ‘The Space Industry’ podcast. Thanks for spending time with us today.

Victor: Hello Hywel, Nice to meet you and for the opportunity.

Hywel: Okay. Let’s get into the technical information. We still live in a world where planning for payload interfaces is done in quite a non-standardized way.

In some cases with the CAN, UART, I2C, RS485, all of these different hardware interfaces, and then with even more custom protocols on top. In your view, is standardization a good thing or a bad thing?

Victor: In my view, standardization is always a knife with two edges. On the one side, it’s really nice when we have something like the USB. When you think about it, people who are users of a PC, they never think about USB and they never think is my USB stick going to be okay for this computer or that computer. All computers that have the USB, they support it. And on one side, standardization is awesome because of this, but on the other side, it also slows down progress.

So the way that I see it, if you standardize too much, you are constraining and leaving people less room to do some innovations and to optimize in some way. If you go the other way, it’s the extreme that we have right now in the space sector, which is almost nothing is standardized. There’s so many protocols, probably every payload provider out there and every supply provider out there has their own.

And at some point, any integration is not just sticking areas be it in the PC, but it’s writing all the drivers from scratch. So there is pros and cons, but definitely a situation where you’re in one of the two extremes is always negative for one reason or another. And I think in general, what I’ve seen is that most standardizations, they come up when someone has become really tired of having to customize all the time and when they just decide, oh, I’m just going to take all of this and I’m going to make it into something really compatible.

But guess what? Usually the person who starts this or the company starts this, they’re not the only one. Usually a lot of these are flowing around. So definitely some form of standardization is good. Being flexible is good. And in the end, it’s a trade-off between being able to have more flexibility on the payload side and being able to be really optimized and focussed.

Hywel: Is there an impact on cost and timings in terms of the engineering, if you spend time on different routes, standardized or not standardized?

Victor: There is a lot of difference because if you try to be one key that fits all locks usually means that there’s going to be a lot of overhead on top of you. So if you try to support everything all the time, it really puts a lot of difficulty on a system.

And the way that we approach this at EnduroSat is that we have set up on the hardware side what we consider to be really needed by 95% of the market. We’re seeing most commonly in the market and what most people are looking into. And then on the software side, we try to be as flexible as possible because the truth is that we live in a world where hardware change is not so necessary if you have the right software running on top.

So this is something that we’ve learned and tried to use and to impact our customers by giving them something simple and something easy to integrate.

Hywel: And obviously the teams building payloads and companies building payloads are looking to work seamlessly with platform providers. You provide satellite services for shared and dedicated missions. What do you do at the company to make sure that payload teams can work seamlessly with you and remotely, which has been such a challenge over the last couple of years?

Victor: Regarding the actual integration, one of the things that we have undergone in the last year is we have launched our protocol that is called SPS-1, which is really made to simplify the customer’s life.

So one thing that it does is it allows you to automatically generate the full set of drivers from our platform to a payload by describing the functions of that payload in an ideal, in an interface design language. So a customer at this point, as long as they integrate this protocol on the very basic level with their payload, and we provide libraries for the most common operating systems like bare metals or RTOS, like Linux versions.

And as long as they integrate this, they don’t have to write from scratch all the functions of their payload and to give them to us and to lose literally in some cases months to try to be able to use their functionality and to try to use their commands. What they need to do is just describe in a very simple file, these interfaces. And then the full driver on top is automatically generated so that you literally send us a file. You integrate this very basic layers of the protocol. And as soon as we plug this file into our system, you get off the shelf integration with the platform and you get off the shelf integration with the graphical user interface that we have for it.

So you literally can command your payload from the graphic user interface we give for our platform, which in our review and in the feedback we’ve obtained so far is really a time saver. Because in most cases, the customer needs to spend months developing something like this themselves, which is not always compatible with what the platform provider does. And it can take an even longer time to integrate it.

Hywel: Testing and qualification is so important though, in that process. So in the system that we’ve just described with such protocol automation, how do you do tests such as hardware in loop, software in loop or AIT. How do they work in this environment?

Victor: In the shared sat context, what we do is we expose a flat sat. Basically a satellite assembled on the ground for the purpose of testing. We expose a remote connection to it for our customers, and we integrate their payloads in the same hardware configuration in which they will actually fly. We don’t really focus on emulating the satellite because the assistant like this, you always miss something if you try to emulate it all, fully on the software level, but we actually connect the real hardware or equivalent hardware, like the one which is going to fly with an engineering model of the customer payload, or simply expose the payload remotely to it. And the customer is able to connect to it and to literally play with how they would operate their payload.

And one thing that we do there is we introduced this whole system to a hardware in the loop simulation, which is integrating it the way that it’s going to be in space or things like the ADCS and the orbital position. It’s simulating what the different sensors are going to experience so that we can even play on the operational modes.

So we can simulate situations where the satellite is tumbling. What the sensors are going to measure, what the temperature is going to be. Of course, measurements of the sensors really give a complete end-to-end simulation of the system in order to track any ambiguities in the operational modes, in any situations where this is not going to be the way that they’re formulated is not going to be optimal or going to be dangerous so we can correct them.

Hywel: Do you have a sense of net effect on engineering time and costs, and even lead time for systems are with GUI based interfaces for remote integration and testing, like you just explained?

Victor: One estimate we have is from one of our customers that is flying a payload computer. They have their own device for performing high speed computations on the satellite and processing data on the satellite.

And they’re based on a Linux system. And one of our estimates for how much time was spared is literally in their case, they had about three days from getting the driver and integrating it in their device and being able to actually call functions, which are integrated in our onboard computer. And to send files to their own computer, to execute call on their own computer.

This literally something which would have normally taken months as opposed to a few days. Now this is not always going to be the case. Of course, it depends a lot, in this case, we had the driver for the exact architecture of this device, but the point is that even with the full adaptation needed to modify the protocol to a different architecture, We are looking at weeks as opposed to months.

So at least a few times fold the decrease in integration. In terms of ease of use, something that we’ve noticed is that, especially with some of our academia and agency customers, in many cases, they have a lot of equipment available to them in universities and large agencies, of course, but especially for smaller startup companies, this may not always be the case.

They may not have the most expensive spectrum analyzers, or they may not be able to have the full set of equipment they need to test something like a power system. And when delivering complete platforms, the benefit of this GUI approach is that you don’t need additional ground support equipment.

You really need your computer and the appropriate cable to connect to the satellite. Everything that you need is information from the satellite. Everything that you need to measure is already provided there. So it really saves a lot of time when it comes to having the full AIT performed, especially when you’re a startup, because things that would normally take you a lot of specialized equipment, a lot of effort and costs can be done really quickly and easily.

Hywel: What about teams and companies that are developing payloads that have an element of proprietary technology that they really want to protect. And they are most likely looking for privacy while developing the payloads and AIT both on the ground and while operating the system in space, because you’ve discussed, the systems with a lot of remote access and sharing.

How do you address the issues of privacy or payload, operation and data protection? And also as a bit of a follow-up to that, does this work differently for shared satellite missions versus dedicated satellites?

Victor: That’s a great question. It’s one of the things that we always start with, especially with commercial customers. The full system, the way that we have designed it has several layers of encryption. The most important one when we’re actually in flight is the encryption on top of the RF channel. So any data that the customer wants to get to their payload or get down from their payload, goes through a fully encrypted channel.

And on the ground immediately after it’s dumped on the physical ground station, it gets sent to a cloud account, which is also fully encrypted. It’s end to end encrypted from the moment that the customer wants to send data to the moment they receive it. And this thing is just our encryption. But the customer can actually encrypt their data on top without us having to understand it.

So a payload that’s integrated in our shared satellite platform or in a dedicated platform, doesn’t matter. It can inherently encrypt any data which it transmits or so uplinks or downlinks. I’ll give you an example. If you’re doing sensitive information, if you don’t want your data telemetry to be understood by the platform provider, even though you have all of these assurances, if you want to be absolutely sure that there is no physical way, or if you have images that you really need to encrypt, what you can do is any such data stream that comes out of your device, you can already encrypt it in your device. So we don’t need to know what the data is when you transfer it.

So we’re acting like transparent provider of data channels up and down to the payload. Of course, to command the payload we must be able to know its functionality in this type of idea that I discussed. We must know what the payload can do, but we don’t have to get any of its information. So you can just send commands to it.

And then as soon as any data is generated and it needs to be downlinks, it can be fully encrypted by the customer. So not only they can decrypt it on the ground, in their secure account. This is something that I believe we’re going to be seeing more and more in the future happening. The good news about what I mentioned as a ground architecture for the AIT and the remote integration is that, we’re actually using the exact same architecture we use for the in-orbit operations, as the one we use for this type of testing.

In fact, we even use UHF or S band, depending on the type of payload channel. So the flatsat is not actually connected directly to a network it’s RF device, S band or UHF/VHF, is connected to an RF cable and attenuator to what is the ground station computer let’s say. And on the ground, when we do this kind of testing the system level, testing the integration tests, we actually do it with an RF connection. We don’t do it by having the full satellite connected over a cable. We do it in the same way that you would do it in space with the only difference that the satellite is on a table and you have an attenuator instead of having the satellite in space and the free space attenuating the signal.

So they can benefit from exactly the same reliability and exactly the same encryption, so that even if a rogue employee goes through to take out their payload from the table, only they have the encryption in their own premise. And this is not physically possible to touched.

Hywel: You touched briefly on the future there, the sort of approaches that you were expecting to be seen in terms of ensuring the privacy of the data, et cetera. I wonder if you could just explain a little bit about, just as a final follow-up, how you see the future of integration and operational challenges such as those we’ve discussed today in general, evolving in the next three to five years?

Victor: I think that the smallsat sector is maturing really quickly. One of the things that we have noticed is that two, three years ago, encryption was very rare in the subsystems. And now a lot of customers want it. A few years ago, they were considered really still on the toy level. And now, I don’t think anyone is doubtful that you can have hundreds of these satellites generating a tremendous amount of data and actually doing better than one large satellite for certain applications.

So I see a lot of maturity and I think that this maturity is going to go two ways. On one side, there is the people who try to approach small satellite segment like classical satellite segment, and they try to push all the regulations and all the, I would say bureaucracy of a large satellite segment, which I don’t think is going to work because you’re just pushing complexity in a place which is good because there is no such complexity.

I think such companies that try to push too much regulation and too much classical satellite know-how in small satellite, they’re just going to make one generation of nice satellites and then be scared to innovate like it is with the bigger satellites, but the alternative is to really always stay ahead from the edge of what’s possible.

So I think that the integration challenges are mostly going to be related to having more digital twins, to having more places to actually run and test, to have really completely remote satellites. When you think about it, even if you have subsystems in different countries to be able to integrate them completely remotely and to test that this thing works as a single system and to really show how it would work at some point in space, even if you don’t have them physically.

And in the current era where I would say we are decentralized and cloud oriented, companies that ride this wave of digitalization of technology, I think are going to really benefit tremendously on the long run and produce the best.

Hywel: Brilliant. That’s a vision that would really democratize and open up the space industry across the world by removing the barriers during integration that can exist.

So thank you, Victor. That’s great. I think that’s a good place to wrap up. Some really interesting insights there for our audience into how different integration mission design challenges have been solved today, which is great. Thank you very much for spending time with ‘The Space Industry’ podcast community.

Victor: Thank you!

Hywel: And to all our listeners out there, thank you very much for listening and hope you enjoyed the episode too. Remember that you can find out more about EnduroSat on satsearch.com and we’ll share the links in the show notes to the company’s pages. On the platform, you can find out further technical details about their company’s portfolio and make requests for technical information and documents, ask for introductions to the company, quotes or whatever else you might need for your trade study or procurement purposes.

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. To 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.