Electronic Systems Engineer

Every vehicle we ship carries a control unit, communication buses, sensors and an HMI, and above them Synapse, already running maintenance, routing and cost for customer fleets. Your layer is what makes that layer trustworthy. If a signal is missing, late or wrong, an agent takes a decision with a physical consequence: a delivery that does not happen.

The demanding part is the lifetime. These vehicles are type approved and they live seven years on the street, in the hands of drivers who are paid to deliver, not to update firmware. What you write has to be updatable on a vehicle that is working, recoverable when an update goes wrong, and diagnosable remotely. The European cyber resilience regulation makes product security a design constraint from the first commit.

It also fails in ways a bench never shows you. Vibration, damp, a connector a fitter pulled the wrong way, an intermittent bus fault that only appears on one route. We have our own test rig and vehicles in real operation, so you can chase those faults instead of guessing at them.

The software above you is a colleague, not a vendor. If an agent needs a signal no sensor produces today, the answer can be to add the sensor to the next production run. Very few embedded roles let you change the hardware to solve a software problem.

Responsibilities

• Develop and maintain the vehicle's firmware: control unit, communication buses, sensors and HMI.
• Design the over-the-air update path: staged rollout, rollback, and a vehicle that stays safe when an update fails.
• Build the telemetry and remote diagnosis Synapse relies on, and decide which signals are worth sending.
• Apply product security by design, with the European cyber resilience regulation as the reference.
• Debug faults that only appear in real operation, using the test rig and vehicles in the field.

• Embedded development in C or C++ on real hardware, not only in simulation.
• Fluency with vehicle communication protocols and with debugging what only fails on the street.
• Experience shipping firmware to devices you can no longer reach with a cable.
• Comfortable reading a schematic and arguing about it with the person who drew it.
• Based in Seville or willing to relocate.

Counts in your favour

• Product cybersecurity, secure boot or signed over-the-air updates.
• Battery management, motor control or power electronics.
• Type approval or functional safety processes.

You will fit here if

• You want your code moving something physical, with the responsibility that carries.
• Debugging with an oscilloscope in one hand is normal work for you, not a step down.
• Here the rhythm is set by production runs and type approval. A change can be right and still wait for the next series, and that frustrates a lot of good engineers.
• You would rather ask the mechanical team to move a bracket than work around it in code.

• A vehicle platform already in customer operation, where your layer sets what the software above can do.
• Our own test rig and vehicles in the field, to reproduce faults instead of guessing at them.
• Influence over the hardware: if the software needs a signal, the next production run can carry the sensor.
• 100% on-site work in Seville.

What the process looks like

1. Intro call with our team, 30 minutes.
2. Technical conversation about firmware you have shipped and how it failed in the field.
3. A working session on our on-board architecture. Discussed, not submitted.
4. A day in Seville with the team, the workshop and the test rig.

These steps can be completed in ten days.