Software Engineer, Simulation and Modeling

• Strong software engineering in Python (and ideally a compiled language): clean architecture, version control, testing, code review, packaging

• Experience building a simulation or model of a physical system that others used, and validating it against measurement or real data

• Numerical and scientific computing: NumPy/SciPy or equivalent, vectorisation, performance awareness

• Working knowledge of at least one of orbital mechanics and access computation, RF link budgets and propagation, or signal processing

• Habits that make results reproducible: seeds, configuration management, data provenance

• Clear written and spoken English

Nice to haves:

• Constellation, mission or system-level modeling and simulation (STK, Orekit, GMAT, Basilisk or in-house)

• Radar, EW or emitter modeling; scenario or order-of-battle generation

• TDOA/FDOA/AoA geolocation or estimation theory

• Synthetic I/Q generation, GPU acceleration, or real-time and hardware-in-the-loop interfaces

• Cloud-native deployment, containers, workflow orchestration, and data stores for large runs

• A simulation framework of yours that outlived your involvement in it

• Eligibility for national security clearance (an advantage)

Our benefits are designed to support your health and wellbeing, at work and beyond. We keep improving them based on employee feedback, and offerings vary by location. Talent Acquisition will confirm what applies for this role and location during the process.

• Software Engineer, Simulation and Modeling

• Location: Valencia

• Reports to: Reports to: Laboratory Lead & Test Architect

• Employment type: Permanent

• Workplace model: Hybrid

• Employment is subject to applicable security screening (incl. SUPO, where required)

As a Software Engineer, Simulation and Modeling, you'll build the software world the satellites live in (orbits, emitters, signals, truth and scoring) so the whole team can ask "what if" and get a number back. ICEYE is building a space-based RF constellation covering 100 MHz to 30 GHz alongside its SAR fleet, and the Experimentation Lab in Valencia is where we develop, simulate and validate that capability.

Customers and our own engineers ask questions we currently answer by hand-waving: what revisit a cluster gives over an area, how many emitters we detect in a crowded scene, how geolocation accuracy moves with cluster spacing or timing error, and what a next-generation architecture choice buys. The answers need a simulation framework that models the constellation and the emitters end to end, generates the signals each satellite would see, and scores what comes out against a known truth. It doesn't exist yet. You'll build it, and it will become a tool used by engineers, analysts and customer-facing staff.

You'll work daily with the lab, signal processing and ground segment teams, and you'll have direct influence on how ICEYE builds and proves this capability.

• Model the constellation: orbit propagation, cluster geometry, attitude and pointing, antenna beams, access and contact windows, with spacing and timing as swept variables.

• Model the emitters and the theatre: emitters as state machines with real antenna patterns, scan behaviour, modes and duty cycles, placed at order-of-battle density. Start from the lab's real captures and extend synthetically.

• Generate the signals: propagation and link modelling (path loss, delay, Doppler, ionosphere in the low band) and synthetic I/Q per satellite, at a fidelity the RF hardware and the processing chain can consume.

• Own the truth together with the processing team: a truth ledger of every simulated emission, position and time, kept out of reach of the system under test, plus the association and scoring that turn a run into detection rate, false-alarm rate, geolocation accuracy and latency.

• Drive the hardware together with the RF team: provide the geometry and timing the channel simulator and playback hardware need, so a recorded radar can be heard by three simulated satellites with the right delays and Doppler.

• Make it a platform: versioned scenarios, seeded and reproducible runs, provenance on every result, tests, CI, documentation and an interface that non-authors can use.

• Answer real questions: capacity, revisit and performance studies for the payload, product and sales teams, and architecture trades for future generations.

• 6 months: a first end-to-end scenario (cluster geometry, a handful of emitters, synthetic I/Q per satellite, truth logged, a first score) is used to answer at least one real capacity or performance question.

• 12 months: a reproducible, documented framework runs without you on the team; geometry drives the RF channel simulator; real captures enter scenarios alongside synthetic emitters.

• 24 months: the simulation is part of the end-to-end loop with the flatsat and ground pipeline, runs in regression, and backs performance numbers we put in front of customers.