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

Final version of Tech brief is available here. This tech brief presents the work breakdown structure of the project.

The demonstrator code is on github at: franca_ara_integration repository

  • note that the demo showed at CES (as described in the tech brief) included Adaptive & Classic AUTOSAR ECUs which were provided by the contractor . The code taken from the Adaptive AUTOSAR demonstrator which is AUTOSAR code could not be shared on GENIVI github.

  • we are now working on a so-called ARA-free demo (using recorded data streams) whose code will be available on github

The prototype transformation tool is available on github at: franca_ara_tools repository

The IDL transformation analysis is available there.

Pictures of CES demo, Las Vegas, January 2019

Pictures of ERCC demo (Renesas event, Dusseldorf, Germany, March 2019)

below sections are obsolete


 Early version of flyer

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)

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 deploy 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, the tooling is based on a proper mapping between AUTOSAR Adaptive concepts and Franca IDL concepts. E.g., each operation on an AUTOSAR service interface is mapped to a method in Franca IDL.

The following diagram shows how the transformation tooling interacts with the code generators. The generated code on AUTOSAR and GENIVI subsystems is using the SOME/IP protocol for communication. As the subsystems are integrated on model level, the communication is automatically compatible.

The ARA-to-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. It uses Artop (release 4.10) as an implementation of AUTOSAR Adaptive and Franca 0.13.0. Both are using the Eclipse Modeling Framework, which provides a common way of working with models. 

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?

The current implementation of the model transformations from AUTOSAR Adaptive to Franca IDL and vice versa is prototypical in several aspects. It is sufficient to support the requirements of the Franca ARA Demonstrator, but has to be enhanced significantly in order to be used for production development in actual Automotive projects. This additional step is planned for 2019. It will include the following aspects:

  • AUTOSAR Adaptive version: Currently AUTOSAR Adaptive Platform R18-03 is supported via Artop Release 4.10. As the AUTOSAR Adaptive specification is still subject to change, the tooling has to be updated in order to reflect the latest features.
  • Franca IDL feature set: The current tooling supports only a subset of Franca IDL's features. In a further step this will be extended in order to map as many common concepts as possible.
  • Deployment and configuration: In order to reduce the load on the developer, it would be helpful to map deployment information in addition to the core IDL features which are supported by today's transformation. E.g., this includes SOME/IP configuration data.
  • Test-cases: As the AUTOSAR standard is quite large, a set of test-cases will be developed which checks all kinds of concepts mapped between ARA and Franca IDL. This will be helpful as a reference body in order to better understand how concepts from both worlds are mapped.

Overall, the next step is to develop a (near) production-ready tool, which has the goal of reducing the cognitive load of developers as much as possible. This will lead to less errors and a more reliable communication between AUTOSAR and IVI systems.

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