VECTORIO
EN
EnglishDeutsch

“Limited power, limited downlink: reduce and prove the data before it leaves”

Cluster-grade analytics on a few watts.

Same analytics workflow on payload, vehicle or ground station

The problem
  • Downlink is the bottleneck, so I need to decide what to send before I send it.
  • Our analytics stack needs a server. My payload has a few watts and an ARM chip.
  • When the link drops I lose data or I lose the plot.
With PROTOR
  • Same analytics workflow on payload, vehicle or ground station
  • Continues through disruption, same verified result
  • Products generated on board; only results go down the link

From today to the first result.

What you do today

raw downlink to a ground-station server

The full scene goes down the link before anyone decides what matters, and a dropped link loses data or the plot.

With PROTOR

The same workflow runs on the ARM64 payload and at the ground station, keeps going after a dropout and sends down decision-ready maps with an evidence package.

Your first step

Run one stored scene through the workflow on the ground station and compare it with today's result.

one scene
How it runs

From area of interest to tile grid. Step by step.

Areas of interest are turned into the satellite tile grid that covers them, as a manifest for the next steps.

PROTOR · From area of interest to tile gridrunning
AOI RecordsRandomDataProviderCompute Tile GridCompute FieldsTile Manifest CSVCSV Publisher
  1. AOI RecordsRandomDataProvider
  2. Compute Tile GridCompute Fields
  3. Tile Manifest CSVCSV Publisher
nodes
aoi-gen → Generators.Random
tile-compute → ETL.Compute
manifest-csv → CSV.Publisher
area of interest to tile grid
  1. AOI RecordsGenerates seeded, repeatable test rows.
  2. Compute Tile GridComputes new columns from expressions.
  3. Tile Manifest CSVWrites rows to a CSV file.

A real workflow from our end-to-end test suite; the designer view is illustrated.

What you get. From the first pilot.

Same analytics workflow on payload, vehicle or ground station

Continues through disruption, same verified result

Products generated on board; only results go down the link

Why your tools fall short.

×

Cloud-native streaming and ETL assume stable network and generous RAM.

×

JVM-based engines have large footprints and start-up costs unsuited to small ARM nodes.

×

Custom C/Python reduction code is untested, un-auditable and not portable across missions.

What drives it
  • EDF and EUDIS calls on autonomy, ISR and space
  • SNS JU 6G programmes emphasising device-edge-cloud continuum (cited in Vectorio xG deck)

Your pilot. Three steps.

1

Your data shape

Tell us what data you have, where it lives and what the result must be.

2

A scoped pilot

On your data and your hardware, with the success measure written down first.

3

A clear decision

You see the result against that measure — and keep every workflow and record.

Beta · design partners wanted

Bring us your hardest data problem. Let's solve it together.

A short pilot on your data and your hardware. We agree on what success looks like before we start.