Hola anggar,
Para el modelado del problema te recomiendo el libro "Understanding Automotive Electronics, An Engineering Perspective, Eighth edition" es una de las biblias sobre regulación y control en automoción.
Si necesitas recordar conceptos sobre teoría de control, un libro que se usa como libro de texto en diferentes ingenierías es "Ingeniería de control moderna, Quinta edición, Katsuhiko Ogata"
Si usas Thor, puedes obtener alguna versión de prueba de libgen.is.
Tendrás que revisar el cálculo diferencial, no para programar, sino para entender la regulación programada. La gran mayoría usan la estrategia de aproximación PID (Proporcional Integral, Derivativo). Los cálculos se hacen externamente y luego se tabulan, que es lo que se carga en los ECUs para que nadie pueda realizar ingeniería inversa.
El desarrollo de software de regulación y control en el momento actual, está bastante pervertido y de esto tienen mucha culpa tanto Microsoft como Google, ambos promueven lenguajes interpretados, que no son los más convenientes para procesos en tiempo real por su lentitud.
Ahora estamos en la transición de Java a Python, al menos este último lenguaje es un lenguaje moderno y permite programar con cualquiera de los 3 enfoques (imperativo, orientado a objetos y funcional o de inteligencia artificial), pero al final terminas chocando con el interfaz de usuario en modo gráfico y no hay donde elegir, tal que el collar sale más caro que el galgo.
Yo mismo he sido desarrollador de software (era apasionante) para procesamiento digital de señales analógicas y procesos puntuales (originalmente sobre PDP-11 y después en PC) y la salida siempre era sobre un terminal gráfico (Tektronix en PDP-11 y Hercules y sucesivas en PC) y cometí la torpeza de no creerme el Windows (que en términos de programación, el interfaz de usuario es programación controlada por eventos) y me equivoqué.
Ahora la gran mayoría de desarrolladores de software hacen unas interfaces de usuario espectaculares (puro show), que en la gran mayoría de los casos, solo entienden ellos, sin preocupación alguna por la integridad, tratamiento de excepciones, transacionalidad y ese tipo de cosas que hacen que el software sea estable y de comportamiento predecible. Pero esto ha entrado a formar parte del negocio, todo el mundo ansia la actualización a la siguiente versión, sin ser consciente que dicha versión es necesaria, porque en términos de ingeniería se hizo mal el análisis de la casuística.
Si le planteas a cualquier joven desarrollador que te proporcione el "Diccionario de Datos" del almacén de datos que va a usar su aplicación, su respuesta suele ser ¿eso que es?. Luego mucha verborrea sobre el Reglamento de Protección de Datos y ni siquiera saben lo que se traen entre manos.
Concluyendo, no hay documentación de los API (interfaces de software) para interrogar a los diferentes módulos, por tanto, desarrollar software sin dedicarle infinitas horas a realizar ingeniería inversa, es poco menos que tarea imposible en los Jaguar y cualquier otro fabricante, pues Jaguar no desarrolla el software.
Estuve pensando si responder, porque este tema es muy específico y se sale del contexto de este foro. Me animé, por si mi aportación te fuese de utilidad.
Puede ser de tu interés la presentación de un libro que escribí y será de acceso gratuito y universal, que publicará RedIRIS, sobre diseño y especificación de la Instalación de Comunicaciones y sistemas de tecnología IP asociados, para inmuebles destinados a alojar hospitales universitarios:
https://tv.rediris.es/es/jjtt2023/video ... 018b174f82
Saludos
Javier