Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


In general the trend is quite good for the couple JSON and HTTP/REST, that have the highest scores in our overall popularity score, followed by SOME/IP and FrancaIDL. A little far away, also MQTT and CommonAPI got a fairly good result.

TODO same next paragraph for outside

SOME/IP, Franca and CommonAPI are the preferred option according to our poll when it comes to communication between ECUs. Indeed, it is already available a product that uses the three of them: the CommonAPI Franca-based generators and runtime with SOME/IP bindings. It was then of great interest in our team to understand at which level such toolkit could interoperate with an important ecosystem in the Automotive Industry represented by AUTOSAR ECUs. Out focus went in the AUTOSAR Adaptive Platform because it represents a big trend among OEMs.

Franca/ARA::COM Interoperability


The common basis for communication between the ECUs is established using SOME/IP. 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 were 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 maintaining the service interfaces by having only one source of origin.

The results of this project consolidate the use of Franca-based descriptions of interfaces when designing complex systems by enabling a seamless integration of GENIVI APIs and components into the automotive software engineering processes used for autonomous vehicle functions (a.k.a. Adaptive AUTOSAR). The current implementation of the model transformations from Adaptive AUTOSAR 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. The project demonstrates the value and relevance of the GENIVI vehicle domain interaction strategy through the delivery of tangible and useful technology (e.g. code generators) to implement the interfaces of automotive complex systems. 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.


The team researched the current technologies used inside and outside the Automotive Industry for model-based development and communication. During the research, it It was asked the opinion of some representative of the Industry, that confirmed both the importance of Franca+CommonAPI+SOME/IP and AUTOSAR software stacks in the current and future plans. Therefore, we demoed a possible way to interconnect both developer and runtime environments between them thanks to the concept of model-to-model transformations, introducing a new tool.

During CES2019 and internally in OEMs and Tier1, there has been good feedback for such tool also in accordance of the future plans of development. AUTOSAR Adaptive platform and SOME/IP non-AUTOSAR ECUs are clearly having a trend in the near future, so would make sense to bring the tool to a production-ready level. Thanks to model-to-model transformations we could provide indeed a set of tools for easy and fast connection of domains (IVI, ASIL, DI,...), either via new bindings for the Franca-based tools like CommonAPI, either as separated gateways generated by model definitions.

For the same reason, we do also see the need extend Franca model and CommonAPI bindings to enable DDS, ROS, MQTT, REST, etc. in order to facilitate the interoperability of the traditional ECUs also with ADAS and cloud domains.

TODO: warning: may not be 100% compatibile

TODO: merge last two paragrapths somehow and franca bindings


Last thing