Feature Request for: IDL and code generation infrastructure

[dejanpan]

IDL and code generation infrastructure

Abstract

A runtime solution that shall be able to communicate over SOME/IP and DDS needs the capability to read in ARXML and OMG IDL, which are the description formats used to describe network communication to other nodes based on these protocols. Additionally, the de/serialization of messages is needed to convert internal messages into the respective network formats of SOME/IP and DDS-RTPS. Besides the serialization, E2E protection is needed. 

This feature request is about an infrastructure that allows reading in IDL and generating serialization code. The infrastructure shall be able to deal with IDL and code generators needed for SOME/IP and DDS, and be designed in a way that further extensions are possible. 

Motivation

As of today, there is no (to us known) infrastructure in S-CORE that allows for processing IDLs and generating serialization code. The motivation is to close this gap, as this functionality is essential for a middleware stack. 

More specifically:

• To communicate between processes/network you need to serialize types (CDR or SOME/IP)
• Writing this by hand is tedious and error-prone, so you want to generate date types+serialization
• Existing data types and information is stored in ARXMLs (at least for automotive), you don't want to convert them to another format => should be able to read ARXMLs
• The separation into Frontends that import descriptions, intermediary models that represent these descriptions and Backends that transform the intermediary models into code allows us to easily add more Frontends and Backends without changing existing code

Rationale

The design is based on frontends to read in IDL, a type model that can represent all the possible types in ARXML and OMG IDL and backends to generate the serialization code for SOME/IP serialization in different AUTOSAR flavors and the DDS-RTPS serialization. The design is made modular to allow for future extensions with additional frontends and backends. Frontends and backends were separated to allow for a mix and match. 

Specification

The following existing requirements are addressed by this feature request:

1. Extensible External Communication
2. Safe Communication
3. Supported network protocols
   • The software platform shall support the following automotive network protocols:
     • SOME/IP
     • DDS
4. IDL Support

Backwards Compatibility

not needed as there is nothing related today 

Security Impact

Assuming that we can trust the IDLs that are used to describe the messages exchanged by activities, the only threat would be an attack based on the sending of serialized messages that are composed in a way to exploit a vulnerability in the code generated for de-serialization. This is to be checked with an appropriate Fuzz testing. 

Safety Impact

This features improves safety as it provided E2E checking capabilities for network communication. It provides the functionality needed for the "Safe Communication" requirement.

The code generators will be tool-qualified according to ISO 26262.

License Impact

No impact - Apache License 2.0

How to Teach This

There will be extensive documentation that describes how to use and extend the framework. 

Rejected Ideas

tbd

Open Issues

tbd

Footnotes

[dejanpan]

@qor-lb This is the issue as communicated via email.

[FScholPer]

Hey @dejanpan remember to also create a Pull Request for that Feature Request until the next workshop so that this proposal can be discussed there and a call for contribution can take place. Please consider that there can be also some kind of overlap to other Feature Requests like SomeIP/Gateway.

[qor-lb]

From Weekly 2025-05-26:

• IDL
  • Scopes for an IDL:
    1. ABI compatible data types: defining data types via IDL and (generating) a related type in the programming language
    2. Serialization wrt. communication protocols/external representation: transformation from internal ABI compatible data types to external protocol serialization
    3. Interface definitions for applications/activities: Definition of input/output interfaces for the applications/activities as an exchange format within the users architecture
  • Next steps:
    1. data types: discuss IDL for data types (relates to Feature Request for ABI compatible datatypes #917)
    2. datatype transformation for different external protocols (relates to Feature Request for ABI compatible datatypes #917, Feature Request for SOME/IP Gateway #914)

[LittleHuba]

I would postpone this FR for as long as we can.

While the scopes that @qor-lb posted give a hint of the fields we "might" need an IDL for, it leaves completely open how the IDL should look like. I fear that we will end up with a too complex IDL, if we drive this FR based on the current project state.

My goal would be to first advance with our other FRs to see the exact use case that the IDL should solve. This would give us a clear picture on the set of features it must provide and helps us in determining what IDL is the best fit.

Happy to hear the opinion of others on my thoughts!

[FScholPer]

My opinion would be that this is a task for the #917 Team to define if this is needed and to create a proposal