=Paper=
{{Paper
|id=Vol-2442/paper8
|storemode=property
|title=Towards Semantic Model-to-model Mapping of Cross-Domain Component Interfaces for Interoperability of Vehicle Applications
|pdfUrl=https://ceur-ws.org/Vol-2442/paper8.pdf
|volume=Vol-2442
|authors=Sangita De,Juergen Mottok,Premek Brada,Michael Niklas
|dblpUrl=https://dblp.org/rec/conf/models/DeMBN19
}}
==Towards Semantic Model-to-model Mapping of Cross-Domain Component Interfaces for Interoperability of Vehicle Applications==
https://ceur-ws.org/Vol-2442/paper8.pdf
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