Towards Semantic model-to-model Mapping of Cross-Domain Component Interfaces for Interoperability of Vehicle Applications An Approach towards Synergy Exploration Sangita De, Michael Niklas and Brian Juergen Mottok Premek Brada Rooney Dept. of Electrical Engineering and Dept. of Computer Science and Continental AG Information Technology Engineering, Faculty of Applied {sangita.de,michael.niklas and OstBayerische Technical Sciences brian.rooney}@continental- University(OTH),Regensburg University of West Bohemia corporation.com Regensburg, Germany Pilsen, Czech Republic juergen.mottok@oth-regensburg.de brada@kiv.zcu.cz Abstract—With the increase in demand of services in the require interface adaption [6] at the app component model automotive industry, automotive enterprises prefer to level to achieve transparent interoperability. Since a collaborate with other qualified cross-domain partners to component model is much easier to understand and maintain provide complex automotive functions (or services), such as than code, the investment in MDE (Model Driven autonomous driving, OTA (Over The Air) vehicle update, V2X Engineering) to achieve transparent interoperability among (Vehicle-to-Vehicle communication), etc. One key element in app software components (SWCs) continues to pay back in cross-domain enterprise collaboration is the mutual agreement long-term. between interfaces of software components. In this context, model-to-model mappings of software component models of Current System Engineering models in an automotive heterogeneous frameworks for automotive services and to domain such as SysML (System Modelling Language), UML, explore the synergies in their interface semantics, have become etc. allows graphical modelling of component interfaces an essential factor in improving the interoperability among the independent of software. Typically, an Interface Description automotive and other cross-domain enterprises. However, one Language (IDL) defines the software interface agreements of the challenges in achieving cross-domain component interface between the app component interfaces. IDLs are typically model-to-model mappings at an application level lies in bound to one or more programming language generators. Over detecting the interface semantics and the semantic relations that the time, in the automotive app domain the level of abstraction are conveyed in different component models in different at which functionality is specified, published and or consumed frameworks. This paper addresses this challenge using a Model has gradually become higher and higher [16]. Eventually Driven Architecture (MDA) based analytical approach to explore interface semantic synergies in the cross-domain progress has been made from modules, to objects, to component meta-models that are used for automotive services. components, and now to services [16]. A service is the major The approach applies manual semantic checking measurements construct for publishing and should be used at the point of at an application interface level to understand the meanings and each significant interface. Today most of the SWC interfaces relations between the different meta-model entities of cross- are based on Service Contracts, thereby allowing domain framework software components. In this research, we heterogeneous systems to communicate and interchange their attempt to ensure that interface description models of software services. The SOA (Service-Oriented Architecture) pattern components from heterogeneous frameworks can be compared, allows us to manage the usage (delivery, acquisition, correlated and re-used for automotive services based on consumption, etc.) in terms of, related services [16]. To bridge semantic synergies. We have demonstrated our approach using the semantic gap between the FW SWCs and to achieve component meta-models from cross-domain enterprises, that interoperability by reusing of artifacts, requires understanding are used for the automotive application domain. of the semantic mapping at app SWC interface level [1][9]. The IDLs that are used for automotive app domain SOSCM Keywords—component, Framework, domain, interface, (Service- Oriented Software Component Model) interface semantic, mapping, synergy, metamodel, syntax, application description may need to consider the following fundamental I. INTRODUCTION characteristics[1]: Today’s vehicle electronics are essentially clusters of • Interface type: The distinction of the basic interface heterogenous ECUs (Electronic Control Units) from various type: operation-based (e.g. methods invocations) and suppliers with varying levels of complexity. From simple data-based service interface (e.g. data passing). sensor/actuators all the way up to High Performance • Separation of Interface Roles: The distinction between Computing (HPC) chipsets, communicating over the provides-part and the requires-part of a service heterogeneous communication networks or even off-car to interface. Wireless Networks. The application (app) developers must have knowledge of a wide range of technologies instead of • Interface interaction points: Service interface being focused on a particular technology such as interaction points (e.g. ports, topics, etc.). programming or data interchange. The automotive software industry always looked for means to narrow the gap on the • Method invocation: Method signatures containing way from requirement to software. Therefore, this would information with valid parameter types, e.g. Client- server, Sender-Receiver, Publish-Subscribe etc. Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0) 57 • Attributes: Specification of attributes or fields e.g. getters, setters, Notifiers, etc. • Abstraction of Component: abstract description of the SWC (single or composite) using the interfaces. • Interaction with Connectors: Specification of software connectors used for realization of an interface mapping between provider and receiver SWCs interfaces. • Interface Behavior & Semantic Annotation constraints: The invariants, pre- and postcondition constraints of a component interface internal behavior depends on the state of the SWC. • Interface Binding: The binding type describes the way a vehicle app SWC interfaces binds to a middleware Fig. 1. An Overview of Service Interdependent Communication between the ECU partitions communication protocol for intra- or inter-ECU communication. The authors of [1] proposes a Component Model A component construct fundamentally combines both Classification FW which identifies and discusses the basic service interfaces and interaction description. However, SWC principles of component models. The authors of [15] proposes interface binding to middleware is not considered in the alignment of ontologies of source UML models with semantic current scope to align the focus towards interface semantic heterogeneity into a single ontology or merged coherent synergies exploration for heterogeneous component models model by using a process of detection and resolution of purely at app level. semantic conflicts that may exist among the different UML models. To deal with interoperability, one possible option is A. Contribution of the Report to make each component implement several interfaces, which The automotive industry can be regarded as a complex yet makes the software interface unnecessarily big. A second connected network (ecosystem) of highly interdependent possible option may be to provide different implementations subsystems as seen in Fig. 1. Systems with a heterogeneous of a single component for each of the automotive development implementations, architectures, semantics have to be environments. Such a solution however, will increase the integrated into collaborative environments to support development cost and test effort. A third option could be to automotive complex services. The interoperability between possibly consider the role of connectors in the construction of them has become a major challenge in this new ecosystem, a software system from reusable components that is to thereby generating several research questions about how to consider especially the role connectors should play when the manage the information exchange and collaboration between distribution and deployment of a component-based these heterogeneous system’s FWs at app level with so vastly application is considered, as proposed by authors of [7]. different properties [17]. This paper presents a detailed In this context Software Adaption is a promising approach investigation on semantic survey of the component interface to build flexible interfaces for variable software systems. models of various cross-domain FWs. The paper explores the Authors of [17] proposes adapter systems to deal with service possibilities of semantic service-based interfaces matches and mismatch problems that can happen in the information reveals the areas of semantic mismatches between the exchange in heterogeneous SOA-based environments where information ex-change formats of heterogeneous system’s the interoperability is crucial. The authors of [2] present an FWs at an app level where the interoperability is crucial [17]. automated approach to model-to-model mapping and The proposed solution in this paper is based on exploration of transformation methodology, which applies semantic and component interface semantic synergies [2][9]. Exploration of syntactic checking measurements to detect the meanings and interface semantic synergies could also further aid in SWC relations between different models automatically. The authors reusability in the future. of [11] propose component model-to-model transformations B. Motivation Scenario and Related Work to establish translation of semantics by manual mapping of In the last decade a plethora of different interface programming languages of heterogeneous platforms [11]. specification models or IDLs were designed using different II. METHODOLOGY technologies to support automotive app domain. This could be due to the fact: firstly, coexistance of new ECU HW interfaces With the proposed methodology based on static analysis with legacy as seen in Fig. 1, secondly, the conformance to of interface semantics, we have attempted to provide a level frequent new standards in automotive domain [10], thirdly, the of abstraction at SWC interface semantic specification level non-functional system requirements such as performance and and have defined an abstract UML profile (M2 level) model scalability. Unlike adaption of ADLs (Architecture also called Component-Port-Connector (CPC) model [1] [7] Description Languages) of frameworks that requires adaption [5], to describe each of the cross-domain FW SWC constructs of the entire end-to-end stack at system specification level, in context of interfaces. The SWC constructs agrees mostly to adaption of IDLs would basically focus on adaption of the traits that are visible in the Black-box view of a component. components, ports, connectors, algorithmic code of FW A SWC construct of SOA based automotive app domain FWs SWCs purely at an app level [18]. To increase interoperability fundamentally represents (i) the SWC service-based- and efficient reuse of component interface model, it is interfaces used for the interaction with the other components important to understand the differentiation of component for inter- or intra-ECU communication, and (ii) the means of model interfaces. SWC binding and communication using middleware. With the 58 given approach each of the FW SWC constructs are • Composition level: Connection represents interactions represented using the CPC models, abstracted from the SWC between interface functionalities and behavior in two meta-models of heterogeneous domain FWs. components as far as accessible through SWC ports [5] e.g. Synchronous, Asynchronous, etc. A. Classified Levels for Semantic Survey of Software Component Interfaces Fig. 2 illustrates automotive app domain SWC constructs To illustrate the approach of static semantic analysis of represented by an abstract generic CPC model [1][12][19]. SWC interfaces, we have considered few of the SWC Towards the SWC interface semantic synergy exploration, the constructs of the cross-domain platforms supporting structure of an abstract generic CPC model illustrates the automotive apps. In this approach, Interface Syntactic level abstract view of the components at different containment was not considered as it covers only the syntactic aspect and levels, their interface types, their typed input and output ports, describes the signature of an interface in a FW specific and the connectors between them. Abstraction of the generic programming language and is relatively out of current CPC model emphasize on the common service-based interface research scope. For simplicity, we have classified SWC semantic properties and hide the platform specific details that constructs into three basic levels [1][12] : are not needed in the interface description [19]. • Interface Semantic level: reinforces the syntactic level A generic specific CPC model can further provide and concerns with the meaning of features often knowledge base for future automotive domain specific specified by the expectations and effects of individual software solution such as coherent, unified IDL or a Meta-IDL features. A generalization of this level can be assumed model. With the reference to the abstract generic CPC model, as semantics [12]. we have tried to represent the CPC model for each of the FW SWC constructs based on three identified basic levels: • Interface Behavioral level: represents dynamic Interface semantic, Interface Behavior and Composition [1]. behavior of service-based interfaces based on With the semantic survey we have compared and revealed the constraints (e.g. constraints on their temporal ordering, areas of service interface semantic matching and mismatches precondition, postcondition, invariants, etc.). It among the cross-domain FW IDLs at model level in reference expresses their internal behavior (e.g. internal states). to the generic CPC model. class new _InterfaceModel operation_based Component_spec system_spec Comp_State basic_type Port_based Interface_spec In-interface:Client In-interface:Sender Inv ariant +method request_response_spec 0...* Out-interface:Serv er method_inv okation Data_Passing publish_subscribe In-interface: Subscribe +method 0...* PreCondition Out-interface: Out-interface: Publish Receiv er PostCondition Data_Prototype Input_DataPrototype Output_DataPrototype Parameter Connectors DataType_mapping InParameter OutParameter Binder_class InOutParameter_mapping Synchronous dds Method_interaction gRPC 1...* rest Binder rpc Asynchronous inter_serv ice_comm_protocol Fig. 2. Abstract hierarchical generic Software Component-Port-Connector (CPC) model based on Black-Box perspective 59 III. A SEMANTIC COMPARISON OF COMPONENT CONSTRUCTS model (M2 level) UML profile representation can be seen in BETWEEN CROSS-DOMAIN FWS AND AUTOMOTIVE FW Fig. 3. The Service interface model employed for interface description is specified using various elements, this includes This section provides an overview of abstract SWC [3]: interface model descriptions in context of “constructs”, for those FW components that are used in automotive app • Aggregation of variable data prototypes in the role of domain. The meta-models used for component constructs Events (VariableDataPrototype); identifies the list of relevant concepts and a list of relevant relationships between these concepts specific to FWs. • Aggregation of Getter, Setter and Notifiers in the role of Fields. A Field is a combination of a Remote A. Automotive Domain: AUTOSAR Adaptive Framework Procedure Call (RPC) and an event. AUTOSAR (AUTomotive Open System Architecture) is • Aggregation of Client-Server Operations in the role of widely accepted as the defacto standard of automotive system Methods. Arguments data required for Client-Server software architecture for developing apps of various Operation is represented in the role of automotive platforms during the different phases of a vehicle ArgumentDataPrototype in the meta-model as a pre- life cycle. The AUTOSAR Adaptive platform (AR AP) app condition. Method calls used for communication SWC template meta- model is implemented using ARXML among SWC types in AR AP can be described as Schema. The AR AP SWC has a service provider port synchronous or asynchronous (e.g. fireAndForget). (PPortPrototype) and a receiver port (RPortPrototype). Each PortPrototype is typed using service interfaces. An example The service interfaces instances in AR AP are deployed of AR AP app SWC (release version 18-10) specific meta- using RPC communication. class DOC_ComponentModel G1 AREl ement AtpBl uepri nt AtpBl uepri ntabl e P1 A Semantic Relation AtpType SwComponentType C1 P1 ⊂ G1 P1 ∪ «atpVari ati on,atpSpl i tabl e» AutosarDataPrototype ArgumentDataPrototype Adaptiv eApplicationSw ComponentType C9 + di recti on: ArgumentDi recti onEnum + serverArgumentImpl Pol i cy: ServerArgumentImpl Pol i cyEnum [0..1] C2 +argument * {ordered} +port 0..* AtpBl uepri ntabl e CompositionSw ComponentType AtpPrototype PortPrototype C3 C4 «atpVari ati on» PortInterface Serv iceInterface C5 «atpVari ati on» «atpVari ati on» «atpVari ati on» 0..* +fi el d +method 0..* +event 0..* AutosarDataPrototype AtpStructureEl ement C7 AutosarDataPrototype C8 Field C6 Identi fi abl e VariableDataPrototype ClientServ erOperation + hasGetter: Bool ean + hasNoti fi er: Bool ean + fi reAndForget: Bool ean [0..1] + hasSetter: Bool ean Fig. 3. Overview of Abstract SWC constructs meta-model also named as Graphical Model G1 for AUTOSAR Adaptive Framework B. Infotainment Domain: Franca Framework TABLE I. INTERFACE SEMANTIC SYNERGIES OF SWC MODEL: Franca IDL (FIDL) is developed as a part of the GENIVI AUTOSAR ADAPTIVE VS FRANCA (‘C’ IS CONSTRUCT MODEL ELEMENT) standard Franca (version 0.13.0) FW and supports IVI (In- AUTOSAR Adaptive Franca Component Vehicle infotainment) system’s interfaces. Franca IDL is Component Construct Element Construct Element language binding neutral and independent of concrete C1 C10 bindings. Franca+ IDL (FCDL) provides an extension to the Franca FW that adds support to the modeling of components, C3 C11 composition of components, typed ports (provides and C4 C13 required), port interfaces (optional major and minor versions) C5 C14 and connectors between ports as seen in the meta-model represented by UML profile in the Fig. 4 [10]. Franca FW C6 C19 uses FIDL to define app interfaces and FCDL to define app C7 C16 SWCs and their configurations. Like AR AP, Franca+ FW also supports the CompositionComponentPrototype (named C8 C17 as Component). A component contained in a composition is called Component Prototype. 60 The service attribute marks a component as service at app interface level) meta-model elements of AR AP and running on the target platform. The Methods, Events, and Franca FWs. Semantic mapping of Franca IDL Fire-and- Fields of AR AP service interface are semantically aligned to Forget Method to AR AP app service interface Method can be Franca+ IDL’s (FCDL) Methods, Broadcasts and Attributes. achieved by activation of the “fire & forget” semantics of a TABLE I. illustrates interface semantic synergies (indicated given method by setting the value of attribute by arrows) observed between the app SWC constructs (only method.fireAndForget to value true [4]. class InfotainmentDomain Model «FRElement» FComponentPrototype G2 C10 «FRElement» FCompositionComponentPrototype +port 0...* P2 C11 Serv iceComponentPrototype «FRpPrototype» FPortPrototype C13 C12 «FrancaDataPrototype» +namespace 0...* VariableDataPrototype «FRInterfacePrototype» «FrancaDataPrototype» FPortInterface FArgument C20 + Fversion:major: int + direction: ArgumentDirectionEnum - Fversion:minor: int C14 C15 1..* argument +broadcast 0...* +attribute 0...* +,method 0...* «FRType» «FRType» FNormalMethod «FRType» «FRType» C16 FBroadcast C17 FAttribute FMethod + ClientServerOperation() - FrancaProvDataElementsInterface: Dataprototype - Notification: Dataprototype C18 C19 + Getter(): int + Setter(): void «FRType» FFirenForgetMethod + fireAndForget: Boolean[0...1] P2 A Semantic Relation C21 P2 ⊂ G2 ∪ Fig. 4. Overview of Abstract Component Constructs meta-model also named as Graphical Model G2 for Franca (also Franca+) Framework C. Robotics Domain: ROS Framework as a pre-condition between invoker and invoke, this The Robot Operating System (ROS) developed by Willow functionality is achieved through introduction of the messages Garage aims to provide a software development environment and the concept of topics to which the messages are published for robotics. ROS is a perfect FW for autonomous driving cars for subscription [8]. ROS2 TopicSubscription can be and provides high-level functions such as route planning, semantically mapped to EventSubscription in AR AP. Data connectivity, etc. Literally, ROS (version 2.0) is not a Semantics are semantically similar to the asynchronous component-oriented software. However, like in many fireAndForget Method invocation of AR AP [5]. In contrast to programming paradigms (objects in object-orientation, etc.), AR AP, the concept of a connection does not exist in ROS2. ROS also strives to build apps from modular units. In the ROS Location-transparency between nodes is achieved through the programming model, the modular programming unit is a node concept of a master node. The master node provides naming [8].Nodes are semantically similar to SWComponentPrototype and registration facilities for all nodes [8][5]. In ROS2 in case in AR AP as can be seen in Fig. 5. of the exchanged information having command semantics and being communicated mostly synchronously (blocking mode) A Topic can be considered as a named communication as a pre-condition between invoker and invoke, this channel which is used to send and receive messages between functionality is achieved through introduction of a service nodes and can be semantically mapped to PortInterface of AR concept. The service in ROS2 is defined by a string name and AP. In ROS2 (ROS version 2.0) all the necessary information a pair of messages, a request and a reply message and is exchange among nodes is performed through messages. ROS2 semantically similar to RPC based ClientServerOperation in has two basic types of interaction endpoints attached to a node AR AP. Unlike AR AP, services cannot be grouped through that are data and control interaction endpoints. service ports in ROS2. In ROS2 component models or nodes In case of the exchanged information having data are described using Message Description language (MDL) or semantics (using DDS: Data Distribution Services) and being Service Description Language (SDL) based on data and communicated mostly asynchronously (non-blocking mode) command semantics requirements. 61 class RoboticsDomain Model G3 «SwComponentPtototype,ModularUnit» Node P3 A Semantic Relation Master node used for C22 location transparency P3 ⊂ G3 «ROSApplicationComponentType» ∪ CompositeMasterNode + register_publisher: void + register_service_provider: void C23 - register_subscriber: void «Identifiable» P3 RequesnReplyOperation C29 «ROSApplicationComponent... PortInterface AtomicNode «DataInterface» C25 0...* C26 Topic - is Service: Boolean Data Flow «serviceInterface» - isDataflow: Boolean + ros::publish: Boolean (Messages) ClientServ erInterface 0...* - ros::subscribe: Boolean One Way Data + ros::init(): void Semantics(non- + ros::NodeHandle(): void blocking mode) + ros::SpinOnce(): Boolean C28 «Identifiable» PublishSubscribeInterface One way Semantics Control Flow (non-blocking C27 Two-way Semantics(RPC):Blocking mode - firenForget: Boolean [0...1] mode) Service Driven Fig. 5. Overview of Abstract Component Constructs meta-model also named as Graphical Model G3 for ROS Framework TABLE II. illustrates interface semantic synergies message called an Intent (also an IPC). Intents bind individual (indicated by arrows) observed between the app SWC components to each other at run-time using messages [13]. construct (only interface) meta-model elements of AR AP and However, a data request is treated by the Content Provider ROS FWs. (CP). The requesting data is indicated through URI (Uniform Resource Identifier), which provides the standard access to TABLE II. INTERFACE SEMANTIC ANALYSIS OF COMPONENT MODEL: CP. The communication between various functionalities of AUTOSAR ADAPTIVE VS ROS (‘C’ IS CONSTRUCT MODEL ELEMENT) app components is provided by Receiver of Broadcast and AUTOSAR Adaptive ROS Component Construct Intents (RBI). For the communication, the object Intent must Component Construct Element Element be passed as a parameter for the RBI to search the C1 C22 functionality. The broadcast receiver schedules the JobServices event chains. These Events are semantically C2 C25 similar to Events used by AR AP app SWCs. However, if an C4 C26 app service is used only by the local application and does not C5 C27 need to work across processes, then only a Binder class implementation can provide direct client access to public C6 C29 methods in the service [14]. Unlike AR AP apps, for most of C7 C28 the Android apps, the service doesn’t need to perform multi- threading, so using a Messenger allows the service to handle one call at a time. If it’s important that the service to be multi- D. Telematics Domain: Android Framework threaded, use of AIDL is preferred to define the interface [13]. An Android application runs in its own process and cannot The startService() service method call invoked by a client access the data of another application running in a different result in a corresponding call to the server or service’s process. To allow one application to communicate with Service.onStartCommand (Intent, int, int) method. On another running in a different process, Android provides an successful service connection binding with the stub or server, implementation of IPC (Inter Process Communication) the client receives an instance of IBinder interface using through the Android Interface Definition Language (AIDL). It onServiceConnected() callback method as seen in Fig. 6. allows to define the programming interface that both the client These method calls of an Android app can be semantically and service agree upon in order to communicate with each mapped to ClientServerOperation() method calls and Notifier other using IPC. Four different types of app components are fields of an AR AP app SWC. The oneway keyword modifies used as essential building blocks of an Android app namely, the behavior of remote calls. When it is used, a remote call Activities, Services, Broadcast receivers and Content does not block, it simply sends the transaction data and providers. immediately returns. The oneway remote method calls can be semantically mapped to asynchronous ClientServerOperation Three of the four component types activities, services, and or method calls of an AR AP app SWC. If oneway is used with broadcast receivers are activated by an asynchronous a local call, there is no impact and the call is still synchronous. 62 class TelematicsDomain Model «AndroidApplicationComponentType» «AndroidApplicationComponentTy... Service is a special type of Serv ice Activ ity activity that does not have a visual user interface and usually - isBound: Boolean G4 + handleMessege(): void run in the background . + onDestroy() + Context.bindService() + onPause() + Context.startService() + onResume() + handleMessege(): void + onStart() «signal,message» + OnBind(): IBinder + onDestroy() + setContentView(): int C30 Intent::startServ ice + onPause() P4 + OnResume() + startService() + onStartCommand() Using - showNotification(): int C31 InterProcess Intent is used Communication for IPC (IPC) Protocol. communication such as method «interface» invokation IBinder + getService(): LocalServiceInstance «signal,message» «DataRequestIdentifiable» - onServiceConnected(): Boolean Intent::InitiateBroadcast ContentResolv er - onServiceDisconnected(): Boolean + registerCallback() C34 - delete() + sendBroadcast() - insert() + query(): URI «AndroidService» - update() C35 JobServ ice On Successn of bindService(),Client + JobScheduler() receives an IBinderinstance from Stub or Service «AndroidApplicationComponentT... ExampleContentProv ider «Identifiable» + ContactContract.Data - UnifiedResourceIdentifier(URI): void ClientBindingClass C33 + bindService(): void - onServiceConnected(): IBinder - onServiceDisconnected(): Boolean C37 «AndroidApplicationComponentTy... BroadcastReceiv er «signal,message» + onStartJob() + onStopJob() Intent::Ev ent C36 - RegisterReceiver(): int P4 A Semantic Relation C32 - JobScheduler: VariableDataPrototype P4 ⊂ G4 ∪ Fig. 6. Overview of Abstract Component Construct meta-model also named as Graphical Model G4 for Android Framework Unlike AR AP app SWC model, Android app model does specific software solution for automotive app interface not have ports. TABLE III. Illustrates interface semantic models, aligning ontologies is a crucial issue in the field of synergies (indicated by arrows) observed between the app semantic integration, which aims to find semantic SWC construct (only interface) meta-model elements of AR correspondences between a pair of elements of ontologies by AP and Android FWs. identifying semantic relations. The interoperability of different UML profile-based component interface models TABLE III. INTERFACE SEMANTIC ANALYSIS OF COMPONENT MODEL: (described in section III) within the same vehicle information AUTOSAR ADAPTIVE VS ROS (‘C’ IS CONSTRUCT MODEL ELEMENT) system would require a process of detection of interface AUTOSAR Adaptive Android Component semantic synergies and resolution of semantic conflicts. The Component Construct Construct Elements ontologies alignment can use one or more similarity measures Elements (syntactic, semantic and structural) to detect the set of C1 C30 mappings [15]. To better meet this objective, and to C2 C31 significantly increase the scope of future semantic integration algorithms for automotive app interface models following our C5 C34 approach, an overall semantic ontology mapping must be done C6 C37 between the different component construct meta-models. C7 C36 If we consider G1, G2, G3 and G4 are the graphical model representations of different FW component construct meta- IV. FUTURE SCOPE: SEMANTIC ONTOLOGY MAPPING OF models (as described in section III) and P1,P2,P3 and P4 are specific semantic relations or ontologies included in G1, G2, COMPONENT INTERFACE MODELS OF FRAMEWORKS G3 and G4 such that P1 ⊂ G1, P2 ⊂ G2, P3 ⊂ G3 and P4 ⊂ G4. Aligning semantic ontologies represents a great interest in Then based on interface semantic static analysis approach and automotive app domains that manipulate heterogeneous semantic synergy results, we can say that the semantic overlapping knowledge FWs. For a future general domain- ontologies represented by P1, P2, P3 and P4 are such that P1 ≅ 63 P2 ≅ P3 ≅ P4 with overlapping knowledge domains. Therefore, component models that we have already shortlisted, we would we can also say that I (G1, G2, G3, G4) is the set of isomorphic like to extend our work in the direction of cross-domain or similar sub-graphs [15]. However, such a semantic interface semantic analysis and comparison to explore more ontology mapping could be better explained with semantic synergies between these component models and transformation of the UML profiles in ontologies. automotive standard FW component models in the future. V. CONCLUSION Today the development of vehicle software systems is REFERENCES getting more and more complex and widely distributed. End [1] I.Crnkovic, S.Sentilles, A.Vulgarakis and M.Chaudron, “A users expect faster, reliable and scalable results despite Classification Framework for Component Models”, IEEE Transactions unpredictable changes in the market. With the proposed on Software Engineering 37 (5), 593-615. approach towards interoperability, we were successful to [2] T.Wang, S.Truptil and F.Benaben, “An automatic model-to-model explore interface semantic synergies among few of the cross- mapping and transformation methodology to serve model-based domain component-based software FWs. The app component systems engineering”, Information Systems and EBusiness Management, Springer Verlag, 2017, 15 (2, SI), pp.323-376. constructs dimension refers to the notions of reusability and [3] AUTOSAR, “Specification of Manifest”, AUTOSAR AP Release 18- resolvability, which are important principles of CBSE 10, 2017.http://www.autosar.org. (Component based Software Engineering). The proposed [4] AUTOSAR, http://www.autosar.org, “Integration of Franca IDL SWC approach of interface static semantic analysis ensures that Descriptions”, AUTOSAR Release 16-11,November 2016. SWC interface models of heterogeneous frameworks can be [5] H. Bruyninckx, N. Hochgeschwender, L. Gherardi, M. Klotzbücher, G. compared, correlated and re-used for vehicle apps. The main Kraetzschmar, D. Brugali, "The BRICS Component Model: a Model- contribution of this paper is based on the semantic survey of based Development Paradigm for Complex Robotics Software various cross-domain FW SWC interface models from Systems", Annual ACM Symposium on Applied Computing (SAC). component construct perspective. The FW components [6] T. Pramsohler, S. Schenk, A. Barthels und U Baumgarten, “A layered considered in the research scope are associated with interface-adaptation architecture for distributed component-based systems”. en. In: Future Generation Computer Systems,Elsevier,Vol automotive app domain. Each FW component construct is 47,June 2015,pp 113-126. represented in a CPC (Component-Port-Connector) model [7] D. Bálek, F. Plášil (2001) “Software Connectors and Their Role in format using an UML profile (M2 level) representation based Component Deployment”. (eds) New Developments in Distributed on the hierarchically classified three distinct levels: Semantic, Applications and Interoperable Systems.DAIS 2001. IFIP International Behavior and Composition. The semantic survey of IDLs Federation for Information Processing, vol 70. Springer, Boston, MA. revealed several areas where they provide common extensive [8] A.Shakhimardanov, N.Hochgeschwender, and G. K. Kraetzschmar, support, both in terms of modeling capabilities and “Component Models in Robotics Software”. In Proceedings of the Performance Metrics for Intelligent Systems Workshop (PerMIS algorithmic (IDL) support. On the other hand, the survey also 2010). Baltimore, US. pointed out areas in which existing IDLs are severely differed [9] D.Stampfer, “D2.2.1 State of the Art on Service-Oriented Software from one another. Component Models”, FIONA ITEA2-12038, version 1.0, March 2014. The static interface semantic analysis approach is at a [10] Birken, K., http://www.bmw.com “Franca User Guide”, “Franca Component Definition language Franca+ User guide” “.Release conceptual stage and is carried out manually. The approach 0.12.0.1, Eclipse Foundation, itemis AG, 2013. Release 0.13.0, BMW considered the target meta-model as automotive domain SWC Group,2018. construct meta-model and the source meta-model as other [11] D.Di. Ruscio, D. Wagelaar, L. Iovino and A.Pierantonio “Translational cross-domain industrial SWC construct meta-models, for the Semantics of a co-evolution Specific language with the EMF semantic mapping (or comparisons). With our approach, we Transformation Virtual Machine”, ICMT 2012, pp 71-89. considered AUTOSAR Adaptive app SWC meta-model as [12] P.Brada, “A Look at Current Component Models From Black-box target model. The intention of this consideration of the target Perspective”, 35th Euromicro Conference on Software Engineering SWC meta-model is due to the fact that AUTOSAR has been and Advanced Applications,2009. accepted as a de-facto standard for automotive software [13] A. G. Parada and L. Brisolara, “A Model Driven Approach for Android Application Development”, Brazilian Symposium on Computing architecture. The decision for the selection of source and System Engineering,2012. targets meta-models has been made from autonomous driving [14] H. Benouda, R. Essbai, M. Azizi and M. Moussaoui, “ Modeling and app’s interoperability viewpoint. There is no evolutionary Code Generation of Android Application Using Acelo”, International relation between the source and target. In order to transform Journal of Software Engineering and Its Applications vol. 10, No. 3 source models to target models in future or to evolve the 2016, pp. 83-94. model transformation rules from source to target, semantic [15] H. Elasri,,E.Elabbassi,S.Abderrahim and Muhammad, “Semantic mappings should be built on the meta-model level and used on integration of UML Class diagram with Semantic Validation on Segments of Mapping”,ArXiv 2018. the model level. [16] D. Sprott and L. Wilkes, “Understanding Service-Oriented Considering the context of enterprise interoperability and Architecture”. The Architecture Journal, 1(1):10-17,2004. collaboration that is cross-enterprise, the static interface [17] C. Paniagua, J.Delsing and J.Eliasson, “Interoperability Mismatch semantic analysis and comparison approach could simulate Challenges in Heterogeneous SOA-based Systems”, 2019 IEEE International Conference on Industrial Technology (ICIT), DOI: the process of integrating the information systems of different 10.1109/ICIT.2019.8754991. enterprises for EIS (Enterprise Integration System) [18] I. Malavolta, "Software Architecture Modeling by Reuse, Composition integration. In the last decade, the automotive and other cross- and Customization." Universita di L’Aquila, L’Aquila, Italy, Thesis 1 domain research in the field of Self-driving has facilitated the (2012). development and state-of-the-art so that this technology is [19] RobMoSys,“Block-Port.Connector”, RobMoSys Wiki, June 2017 evaluated nowadays in large-scales on public roads. In this http://www.robmosys.eu. context of autonomous driving functionality, it is worth to mention that for some of the other existing cross-domain 64