Page tree
Skip to end of metadata
Go to start of metadata

Abstract - Gunnar & Philippe

To be filled in the end


Introduction - Giovanni

When designing the current generation of connected vehicles, the automotive industry has to cope with too many choices, too much diversity, too much boiler-plate code, adaption layers, and incompatibility. There are a lot of communication protocols available, each one with different focus.

During the last months, the Generic Protocol Evaluation Project Team identified SOME/IP and Franca IDL (often used together with CommonAPI C++ bindings) as two of the preferred industry options.  On the other side, AUTOSAR and its ARA::COM communication middleware are very important in the automotive environment. When it comes to inter-domain communication between ECUs, messages have to be translated between CommonAPI and ARA::COM. This is not only tedious, but prone to human errors.

However, both communication technologies are based on model definitions (.arxml and .fidl/.fdepl files). This opens the possibility to translate using model-to-model transformation methods that can improve software quality, development time and engineering costs.

In this document we present a tool that uses model-to-model transformation to achieve a compatible generation on both sides of ARA::COM and Franca IDL.  When combined with CommonAPI bindings and ARA::COM runtime, this achieves a runtime translation between the systems.  Using such a tool makes it possible to have a specification in a single format (we propose Franca IDL for this), and yet to use the full advantage of both technologies on both sides of the communication.

The Tool – Itemis (10 lines)

Say hello to Franca model-to-model transformations!

Introduce the solution adopted by GENIVI. Describe theoretically

how Franca/CommonAPI/SomeIP/ara::com are used together. Describe the tools

command line and graphical that are/will be in development. Diagrams.


First proposal:

The Franca project offers not only an interface definition language (Franca IDL), but also a framework for building model-to-model transformations. This framework is being used here to implement transformations from AUTOSAR Adaptive models to Franca IDL and vice versa. These transformations can be used as part of any current Eclipse IDE. For build automation and Continuous Integration (CI) it also useful to apply the transformations as a command-line tool. The goal of the automatic transformations is to apply code generation by AUTOSAR-compatible code generators as well as Franca-compatible generators (e.g., CommonAPI C++) in a way that leads to transparent communication between both systems at runtime. Therefore, a proper mapping between AUTOSAR Adaptive concepts and Franca IDL concepts has to be the basis for the actual transformation tooling. The following diagram shows how the transformation tooling has to comply with the code generator tooling.

The ARA-2-Franca tool is implemented using the Xtend language, which is basically an extension of Java providing language features which ease the implementation of model-to-model transformations. TODO....

Demonstrator - Christopher

Describe the demonstrator. Describe the specific setup, with the interfaces

used and how they are connected and how the tool is used in this case.

Diagrams. Describe the flow of development.

Describe the percentage of code generated vs. manually written. Stress

on the absence of the errors coming from manual adaptation of transports/protocol.

Describe future possibilities and alternative scenarios in which such solution could be used.


First proposal:

The Franca ARA Demonstrator was built to provide interoperability evidences for a wide range of Franca IDL artifacts like message and data types and its mapping to Adaptive AUTOSAR.
The setup consists of four Ethernet connected ECUs running GENIVI, the AUTOSAR Adaptive and Classic Platform. Together, those ECUs form an Emergency Brake Assistant with visualizations on the GENIVI IVI system.

(Image is available for editing:  FARA-37 - Getting issue details... STATUS )
The communication between the ECUs is established via SOME/IP as this is the common basis. However, on top of the protocol stack different middleware such as CommonAPI and ARA::COM is used as binding to the applications.
The following steps had to be executed to establish the communication between the applications:

  • Interface definition using Franca IDL
  • Transformation of the Franca IDL interface definition to an equivalent ARXML definition using the Franca model-to-model transformations
  • Creation of the corresponding SOME/IP deployments for CommonAPI and ARA::COM
  • Generation of the proxies and skeletons for both platforms
  • Integration of the generated code into the demo applications

A clear advantage of following this approach is that there is no need to define the same interface twice in Franca IDL and AUTOSAR ARXML. This reduces errors coming from manual maintining the service interfaces by having only one source of origin.


Remarks:

  • There is no difference within the application if you follow Franca IDL or pure AUTOSAR approach with respect to generated code vs. manually written.

Next Steps – Klaus (Itemis) TBC?

Write about known limitations but in a positive way


Conclusion – Gunnar & Philippe

Recall how much is better to use such tool and in general the approach of

model-to-model transformation instead of adapting every single interface.

Remind to check the GENIVI site for more about this topic and updates.

  • No labels