IDL & Code Generation

Goal

To accomplish multi-generational portability of systems and
applications across suppliers, there is a need to enable
decoupling of human-written functional code from vendor-specific
system deployment architectures, application development frameworks,
communication mechanism libraries and operating system interface
specifics.

Separation of concern

Traditionally, automotive project/system-specific implementations tend
to be very heavily interwoven with technology supplier API
peculiarities and vendor framework-expected application code
structures. This is okay for one-off projects, but not for reusable
code across different technology stacks and vehicle generations. To
address this issue, a key design philosophy is to impose a very
specific code structure requirement for all functional code that is to
be run in the middleware space. For example, one want to have the freedom to
swap communication mechanisms as new improved technologies
emerge. This means the architecture needs to be
simultaneously agnostic and accomodating of different communication
frameworks and protocols. This is accomplished by enforcing a standard
API for the function/application developer to access input data,
runtime parameters, internal state variables, hardware interface
contexts and to populate output data structures.

A standard well defined API is the condition to code generation.

Code generation approach

The isolation of functional code from system-level and
deployment-level context allows for code reuse, rapid system
reconfiguration, prototyping, simulation and advanced fuzz testing
without in-code changes and refactoring when the application lifecycle
standard API is combined with a code generator. The code generator is
responsible for generating the middleware boiler code that gets compiled and
deployed. There is no need for the developer to know how this is done.

This allows eliminating large amounts of
"boilerplate" code that would otherwise clutter human-written
codebases and slow down refactoring. This opens the door to affordable
code base translation.

The only limiting factor in freedom-of-redeployment is if the
functional code's dependency libraries (if any) require
specific hardware or drivers. Abstracting away vendor-specific
accelerator hardware/driver interfaces is beyond the current scope.