Electronic Systems Engineer

Cada vehículo que fabricamos lleva una unidad de control, buses de comunicación, sensores y una HMI, y por encima MothiOS, que ya gestiona el mantenimiento, las rutas y el coste de las flotas de los clientes. Tu capa es la que hace que esa capa superior sea de fiar. Si una señal falta, llega tarde o está mal, un agente toma una decisión con consecuencia física: una entrega que no se hace.

Lo exigente es la vida útil. Estos vehículos están certificados según la EN 17860 y viven siete años en la calle, en manos de conductores a los que se paga por repartir, no por actualizar firmware. Lo que escribas tiene que poder actualizarse en un vehículo que está trabajando, recuperarse cuando una actualización sale mal, y diagnosticarse en remoto. El reglamento europeo de ciberresiliencia convierte la seguridad del producto en una restricción de diseño desde el primer commit.

Y falla de formas que un banco de pruebas nunca te enseña. Vibración, humedad, un conector que un montador tiró mal, un fallo intermitente de bus que solo aparece en una ruta concreta. Tenemos nuestro propio banco de pruebas y vehículos en operación real, así que puedes perseguir esos fallos en vez de suponerlos.

El software que tienes encima es un compañero, no un proveedor externo. Si a un agente le falta una señal que ningún sensor da hoy, la respuesta puede ser añadir el sensor a la siguiente serie de fabricación. Muy pocos puestos de sistemas embebidos te dejan cambiar el hardware para resolver un problema de software.

Responsabilidades

• Desarrollar y mantener el firmware del vehículo: unidad de control, buses de comunicación, sensores y HMI.
• Diseñar el camino de las actualizaciones OTA: despliegue por fases, vuelta atrás, y un vehículo que sigue seguro cuando una actualización falla.
• Construir la telemetría y el diagnóstico remoto de los que depende MothiOS, y decidir qué señales merece la pena enviar.
• Aplicar la seguridad del producto desde el diseño, con el reglamento europeo de ciberresiliencia como referencia.
• Depurar fallos que solo aparecen en operación real, usando el banco de pruebas y los vehículos en la calle.

• Desarrollo embebido en C o C++ sobre hardware real, no solo en simulación.
• Soltura con protocolos de comunicación de vehículo y con depurar lo que solo falla en la calle.
• Experiencia lanzando firmware a dispositivos a los que ya no puedes llegar con un cable.
• Cómodo leyendo un esquemático y discutiéndolo con quien lo dibujó.
• Residir en Sevilla o estar dispuesto a mudarte.

Suma

• Ciberseguridad de producto, arranque seguro o actualizaciones OTA firmadas.
• Gestión de batería, control de motor o electrónica de potencia.
• Procesos de certificación o de seguridad funcional.

Encajarás aquí si

• Quieres que tu código mueva algo físico, con la responsabilidad que eso conlleva.
• Depurar con un osciloscopio en una mano es trabajo normal para ti, no un paso atrás.
• Aquí el ritmo lo marcan las series de fabricación y la certificación. Un cambio puede ser correcto y aun así esperar a la siguiente serie, y eso frustra a muchos buenos ingenieros.
• Prefieres pedirle al equipo mecánico que mueva un soporte antes que sortearlo con código.

• Una plataforma de vehículo ya en operación con clientes, donde tu capa marca lo que puede hacer el software de encima.
• Nuestro propio banco de pruebas y vehículos en la calle, para reproducir fallos en vez de suponerlos.
• Influencia sobre el hardware: si el software necesita una señal, la siguiente serie de fabricación puede llevar el sensor.
• Trabajo 100% presencial en Sevilla.

El proceso

1. Llamada inicial con nuestro equipo, 30 minutos.
2. Conversación técnica sobre firmware que hayas lanzado y cómo falló en la calle.
3. Una sesión de trabajo sobre nuestra arquitectura embarcada. Se discute, no se entrega.
4. Un día en Sevilla con el equipo, el taller y el banco de pruebas.

Todo esto se puede cerrar en diez días.