Bringing Cloud Native PaaS To Space: Onboard Edge Computing f... Adele Karam Hankache & Sergiu Weisz

This talk explores the integration of advanced software platforms with satellite technology, focusing on edge computing for Earth observation missions. The speaker, Adele Karam Onkesh, a solution architect at Thales Alenia Space, presents the NoRKiT project, which aims to improve on-board data processing capabilities. They discuss the challenges posed by existing Earth observation satellites, including limited bandwidth for downlinking data and the inability to update software in orbit. The presentation highlights a shift in paradigm enabled by modern technologies such as cloud computing, AI, and heterogeneous hardware, allowing for real-time data processing on satellites. The project utilizes an orchestrator to manage data processing tasks and introduces unikernels for enhanced performance and security. The speakers detail the system architecture, components like K3S Kubernetes, and tools for application development, showcasing how these advancements could revolutionize satellite operations.

Thank you for joining us for this session. As we promised you with the title of our presentation, we will bring software platforms beyond the cloud, literally beyond Earth, and why not all the way to the satellites. I will start by presented Sorry. By presenting myself. I'm Adele Karam Onkesh, a solution architect at Thales Alenia Space, France. I'm working on several edge computing project and leading a NoRKiT

project, a European project that you will have the opportunity to to describe you on this presentation. And I let my colleague present himself. Hello, I'm Sergiu Voicu. I'm an assistant professor at Politehnica Bucharest, and my main interests are cloud computing, infrastructure, and security. And I am part of the ORKiD project, as well. So, we will start by presenting you the context, the problematics that we have on

our actual Earth observation satellite. As we know actually, the different Earth observation satellite task sequentially. We have a sequential behavior. When an acquisition acquired, we compressed it and stored the data on a mass memory to be transmitted when there is a ground visibility. So, we see that we have also softwares, but the softwares are very tightly related to hardware. We cannot update the different software in orbit

once in orbit. So, we have a complex payloads. We have a lot of a new generation instruments that capture and generate a lot of high resolution data. So, when we have a ground visibility, we are not really able to download all the data and the data can lose their values. So, and with the limited downlink bandwidth, there is a lot of of data available with all without

value on on the board. So, all this can allow us to to think about how we can can do to avoid transmitting data and how we can assess our data directly on the board. And then, there is a new space paradigm. As we we you know, there is a lot of a new space actors, a lot of a new commercial on on this domain. There is also

the new CubeSats and SmallSats. a new business models that arrived and possibilities to use COTS and to to develop around this this possibilities. And we see that in parallel with this new space paradigm, there is a lot of technical enablers with cloud technologies, the virtualized architectures, the new possibilities of communication with 5G. There is a lot of AI capabilities that can be adapted on on board on

actual possibilities. And also, there is a lot of new generation hardware with accelerator capabilities like GPUs, DPUs, FPGA. So, with this new space paradigms and the technical enablers, we can see that there is a big shift in how space can be accessed and how they will be for the next period. So, with this possibility, we can imagine that instead of having a sequential tasking, we can be

able to after acquisition, we store the data in board, and then process them directly on the different hardware and resources that are available on board. So, we can imagine having an orchestrator able to use the different resources available on board to process and schedule applications on the different uh capabilities, and to extract the results needed to be transmitted later. So, we see with this uh mindset, we

can improve on board data processing and use several use cases of AI applications. As you see in the in the figures, we can have, for example, a cloud detection. So, we can launch and execute the cloud detection uh application on board. And when there is a lot of cloud, delete the images. And then, if there is not uh it's it's uh it can be used images, we

can also launch a process, like, for example, ship detection, and transmit to the ground only the coordinate of the ship. So, we can imagine have uh directly access to real reliable information and having missions more efficient. So, what we wanted to present you is a case study, a European project that are actually developed with a consortium of five partners. We are with uh UPB. We We have

also Thales Romania. We have KP Labs and Tarides, a French startup. So, with this consortium, we are uh preparing a a project named the orchestration of reliable computing on heterogeneous infrastructure deployed at the edge. It's a big acronyms. So, this project is the main objective is to put in place an orchestrator able to to use all the hardware capacity on board to execute applications and process data

directly on board. To do this, we have prepared also some tools on the ground level to to help the the end user to and many prepare applications, package them with our software development kit, then simulate them before sending them on the board, simulate the the packaging of this application, and also a management framework to to send data ground to the satellite, and to to retrieve the metrics

and logs from from the satellite. Uh so, what I will present you and zoom on it, it's the orchestrator part, the solution of the software that is on on inside the satellite that we have constituted as a space edge platform as a service. Our target is to have a satellite as a And to to be able to have a satellite as a service, the best actually the

satellite must follow a structured mission plan, like you see in this in this screenshot. We have a structured mission plan with for each time stamp the different events that should be an acquisition or a download. And then we for each for each time stamp we are we have also the description of which instrument will be used, which sensor will be used, and which visibility we have if

we have a ground visibility or not. And what we add to this mission plan, to this actual behavior of a satellite, is the the new capabilities to specify which workflows, which AI services can be launched for each acquisition, for each time stamp. For example, we can imagine having a maritime surveillance, a fire detection. It depends if we are on an ocean or or a land, if the

detector is on top of an ocean or a land. So, we added some more capabilities to to this behavior. And for us, an AI service can be done of a several application that can be in parallel or sequentially. So, we can consider that, for example, we have a pre-processing to prepare the data for the AI application. Then, the AI application can be a several use cases prepared

by our software development kit. And then, a post-processing that will extract the necessary information to be prepared to be downloaded for on the ground. with this this behavior, we can imagine then when in acquisition acquired, when we have a specific time stamp for a specific line, and all the different data are available, the mission data and the the workflow is available, we can consider that our solution,

our platform, is able to schedule the different applications to process the the acquired data, the specific acquired data for this time stamp, and to prepare the results to be sent on the ground. I think that it's familiar for you. It's what we can retrieve on on ground platform. We can see the different level on top of hardware, but of course, our hardware, our onboard hardware were limited

on on CP on resources. So, we can target it a hardware that are proven in flight that are so limited and on top of that hardware hardware, we have imagined a platform that we can retrieve all So, infrastructure services with several with several services for storage networking and the platform as a service from the run time to the platform services. We have the this three layers and

on top of this onboard platform, we can have several services that we can run on our platform. The target is to have several hardware. We We We imagine having a agnostic to be able to install it and configure it on different capability capability of hardware. Can imagine having Nvidia GPU a versatile with FPGA in LX with arm CPU and also we targeted an MPPA uh Cadre. So,

the target is to have a to be able to have a distributed setup, a complex distributed setup with several kind of hardware that can be considered as the same cluster. And the most important things that with configuration, we can be able to configure each applications if we will need to to run it on a classic CPU or it's more to be accelerated on FPGA or on GPU.

So, by configuration we can efficiently configure the different resources on board. as you see cuts on on this slide, we have take the time to do a benchmark state of the art also to to choose the different CNCF solutions that we can use on our solution from runtimes to service platform. Of course, we have also specific services for us that we developed from scratch to to answer

for for the mission of of satellites. I let my colleague continue explaining the different solutions that we that we choose. I let's the floor for you, Sergio. Thank you. So, let's look at Orchid project layer by layer. First of all, unikernels. Who here knows what a unikernel is? More people than I expected, frankly. So, a quick prior primer for unikernels. They are application OSs or library OSs.

You take a kernel purpose built for each application. You take the application code, build it together, and run it inside of a machine, a virtual machine over a hypervisor like QEMU or Solo5 or others. Why would you do something like this? Well, the resulting binary is actually quite small in the tens to hundreds of megabytes instead of how big the OCI images we have today. Performance is

actually better demonstrated on unikernels because you have a single address space, so you don't have the overhead of doing um context switches of of going into kernel space. You have a single address space. And you have an added security as compared to to containers because inside of a container you can still affect the underlying kernel of the operating system you are working on. While inside of a

virtual machine, you cannot easily escape the virtual machine. So, we have chosen two two frameworks for running unikernels. These are MirageOS and Unikraft based on our benchmarks and the usability that they offer, they are the best suited for our project. Okay, so we want to run unikernels, but we want to run them inside of Kubernetes so we can orchestrate them. How are we going to do this?

How are we going to include unikernels in Kubernetes? Well, we need a runtime. A runtime which is able to run unikernels as containers, uh run Unikraft and MirageOS specifically, and it plugs into Kubernetes and its derivatives. So, we have done systematization of knowledge and we have discovered that RunC actually serves all of our needs. It's an open source runtime. It can run MirageOS and Unikraft. It runs

on QEMU. It runs on x86. It runs on ARM64, which are our target platforms, and it can support OCI images so we can use the same image registry to push all our applications and the rest of our code for the Orchid Okay, we want to run unikernels, but unikernels, as I've said, are a single kernel for a a whole application. Are we going to implement drivers, for

example, for Nvidia, for Xilinx, for other accelerators? That would be a lot of hard work that is not worth it. So, we still want to use accelerators because they offer high performance for workloads that need it, such as image processing that we are going to be using inside of Orchid. Uh these accelerators will be included in the next generations of satellites, so we need to use them

and we need this kind of interface to work with it. Current unikernels cannot run on accelerators, so we have implemented an our own project called U K Excel. This offers a TCP interface for unikernels, which a unikernel can call it and it can offload the job for that needs to be accelerated. It can load the blob, it can load the input files, it can run inference on

it. It was built in house and it is based on V Excel, a service that already exists, but as opposed to V Excel, U K Excel does not need dynamic linking because you are going to be running in unikernels in a single address space that does not have dynamic linking. Everything is statically linked in unikernels. Okay? We have our run time. We know how to accelerate our

unikernels. We know that we're going to use unikernels, but which Kubernetes are we going to use? There are many different variations and actually we have here an option that is not Kubernetes-based that we can run on the edge. Which should we run? Well, we did a systematization of knowledge again we have looked through them all and we have chosen K3S because it is lightweight. It has been

proven through benchmarks that it runs faster than the others. It is simple to set up and it is very modular for our use case, so we can do a easy setup with it. So, let's look at the notes. This is a deployment of the pods and our own in-house developed software for the Orchid project. And let's take them piece by piece. First of all, everything is going

to be running on K3S over K3S. What we are going to run on it? For example, the monitor manager, which is going to be aggregating all the monitoring on the control node and it is going to be sending it later to the ground station to a communication manager. We're going to have the storage manager. This is an API which stores information about all the files that are

on the shared file system. This also manages the shared file system and the application storage, which is going to be Zot. The mission manager, which is but a mission plan that Adele has showed into an actual Argo workflow and last but not least the security manager which will ensure the security posture on the satellite meaning that we have all the security features required on the On the

compute node, well, here it's far easier. We only have the orchestrator on top of which we are running a containers for monitoring and we are running the runtime you run C which will be be starting chemo which will start unikernel which can run its own unikernel and it can also run MirageOS. Now let's take the different solutions that we have implemented. First the storage the shared storage

solution. We need a POSIX file system that is distributed and this it is mounted on all of the nodes inside of Orchid. Orchid of course can be can be run in a single node environment in which case you do not need EOS the shared the distributed file system that that EOS gives us but when you are running on a multi-node system you're going to need it so

you can have the input files and the output files shared in a single place because we we orchestrate on multiple nodes. We also store inside of this storage manager we store the applications it runs the Zot registry it implements database for file for file and application management. So as we see here the API basically offers endpoints the files storing the applications and deleting them from the database

and it also monitors the file system for discrepancies so you do not want dark data popping up inside of your file system that means data that is not accounted for you do not know where it's coming from and also the reverse you do not want to see that from the file system poof some some nodes some files are gone. You want to keep track of those and

this is what the the storage manager does. The workflow manager is something that we have also done in-house. It takes a mission plan that Adel has showed us earlier. It turns it into a priority queue, which is going to be sent into Argo workflows, and Argo will then trigger through the K3S API pods, which will execute the workflows inside of Unicorns. We have, of course, added some

glue code as well over over the regular Argo workflows because we need copying of the input files, copy out of the output files, and we also needed a mechanism for preemption based on the priority mentioned inside of the mission plan. And for monitoring, we are collecting both logs and metrics from Argo, from the system itself, and from K3S. They are all aggregated from the compute nodes on

the main node. And Vector is going to be used for aggregation, and then through an API depending on the satellite, of course, we are running inside of a simulator. It These files are going to be sent the monitoring and metrics to the ground station, where it is going to be ingested through Vector again inside of an OpenSearch instance, or inside of a Prometheus, which has a Grafana

over it, so we can visualize the Okay. We've seen all that Orchid can do, all that it has, but let's actually see go through all of these components and see how an orchestration is done. We start from a mission plan that is uploaded to the satellite, and when the time is right and an acquisition is triggered and the camera captures a picture. This picture is going to

be stored inside of the physical storage, and on the physical storage it is going to be put inside of EOS, and inside of the database that we have the files on. This will also trigger the mission planner. The mission planner is going to take in take in the mission plan, and it is add the workflows in to Argo. Argo will will trigger K3S and this of course

will start your run see on a compute node that has the the necessary requirements. This will start the step which will be mounting the files through 9PFS because we need the input files inside of the It will start Kimu and Kimu will do the processing. If we need acceleration to then it is it will do a TCP call for example to start an inference with the with

the input data to an accelerator. It will do the acceleration, it will do the job and then return. So this was Orchid. We would kindly ask you to follow us on LinkedIn, to follow us online. It will be it will help us. This project is going to be an open source project so please follow us if you are interested in any news and if you want to

use our project yourself and of course you can contact us anytime. We also have our emails on the first slide. We also have flyers with us. If you want to see more about the project, you can find us on the street. Just ask us. I'm always happy to talk about Orchid and I will give Adele the pointer for the conclusions. Yes, thank you Sergio. So we can

consider that we have proven the possibility to have a distributed platform on board of of a satellite. All right, we have a demonstrator. We will reach TRL 6 normally and as we know we have several security concept on satellite environment but we have the road is a little bit far but we are working to industrialize this kind of solution. Our future vision as we have addressed a

solution into a single satellite, we wanted to go further to address a federated multi satellite or constellation to to be able use resources between different satellites on a constellation. So we can consider that we have an impact we unlocked new possibility with the use of our software development kit. We can imagine having more and more industrial companies that can prepare application, prepare use case and use a

satellite platform we also have targeted and have a good impact on having a satellite as a service and autonomous aircraft, I think. So thank you very much. If you have a question and also don't forget to give us a feedback for this presentation. Sound check. Do you have any recovery strategy? We are we are working on on this topic for for other project as our project is

really a demonstrator project but this something that we have to address and to to take in place and we have also some works with our partners with KP Labs that embed the solution into their Linux with Yocto so they work also for some recovery strategy in parallel. Thank you. Hi. I was wondering do you have any challenges you had to overcome with Orca's with it being a

satellites far away and the up-link being maybe not so reliable or very slow or something like that. Yeah, but by having this a possibility actually we targeted a low orbit or middle orbit. So and we imagine having packages as we described it's lightweight packages. So normally we have some challenges we we should address how we will send them and what we we we think about it is

that an operator can can have a a um the mission plan with different workflows and applications ready to be sent at the same time for a specific orbit. So yeah, we have some challenges in on sending but it will be less than transmitting all the huge data that is acquired actually by this new generation of instruments. Don't know if you want to add something, Sergio. Uh no,

this is really hardware dependent the the question but from at least what I know with the current links, it's not that big of an issue. Mhm. They can get to gigabytes from what I understand in the CEO project. >> No. Thanks. Hey, um I'm wondering how are you handling the Kubernetes up upgrades? Cluster upgrades. It's a good question. normally we imagine embedding them with the Linux capacity

and we will have the re re uh install or re having re-upload the possibility with the Linux version. Mhm. All right. Hi, how are you doing? Two-part question. So, I see you're running only one control plane server. How do you handle application persistence if the control plane were to go down? There we are not running services though. We are only running processes or applications apart from Victoria

metrics and some of the others. And persistent we are we are using volumes. And the database and everything in the back end. So, it's just How do how do you handle in any kind of Kubernetes Yeah. deployment. Okay. And second question, do you do for your application stack, do you do over the air updates at all or is it just static? Static. We we have not gotten

there yet. Mhm. But as we see it, it's going to be static. Okay. >> As the deployment. Okay, two questions. First, who is actual data consumer in in that project? And the second, do you have any pieces of this software shared on GitHub or somewhere else? Um concerning the data consumer, uh we targeted end users normally as we we considered that we can have several use cases

like fire detection or ship detection. We targeted an end users. But it's a demonstration application. We are working on exploitation plan. But yes, it can be any end user. They need some useful information directly from the satellite. And the source code, normally it will be open source at the end of the project. So, expect end of May, beginning of June, the project is going to be open

sourced. We have to. So, if my understanding you are transforming a generally traditionally network element, the satellite, to a compute, right? Yes. What throughput are you really expecting in this case? Like traditionally you send the data raw to the ground and process it to on the ground with whatever powerful machines you wanted, right? Here you seem to be transmitting directly processed data. So, did you measure the

gain in doing that in space versus rather doing it on the ground? What's the big gain? Like we talk latency, of course, ground to satellite and back. What kind of satellites are you talking about? Like geostationary, LEO satellites? We targeted low orbit satellites for now and the gain on it's as I said the the instrument huge data actually and and for the ground visibility it's not enough

to to send all the acquired data. So, what we wanted to to do process the data and information from this data and send only what is useful for the end user. So, it will shorten the the time it reduce the the time to have an efficient results of processing. You can imagine that the input files now from the camera are hundreds of megabytes. We're talking multiband pictures

and the output now it's going to be files which are going to be output files like ships are here or something like that. It's not different order of magnitude. We're text and outputs and objects versus actual raw images. Okay, so efficiency is in not sending all the data but only the data that is decided Exactly. Exactly. And also to different missions for the same satellite as we

can update You can reuse We can send more application, other use cases, etc. Cheaper in general as well. Okay, so it it targets application satellites mostly. Yeah. Like weather prediction and all that. Exactly. Can you imagine having several use cases? All right. Thank you.