ArticlePDF Available

Abstract and Figures

Software in modern vehicles consists of multi-criticality functions, where a function can be safety-critical with stringent real-time requirements, less critical from the vehicle operation perspective, but still with real-time requirements, or not critical at all. Next-generation autonomous vehicles will require higher computational power to run multi-criticality functions and such a power can only be provided by parallel computing platforms such as multi-core architectures. However, current model-based software development solutions and related modelling languages have not been designed to effectively deal with challenges specific of multi-core, such as core-interdependency and controlled allocation of software to hardware. In this paper, we report on the evolution of the Rubus Component Model for the modelling, analysis, and development of vehicular software systems with multi-criticality for deployment on multi-core platforms. Our goal is to provide a lightweight and technology-preserving transition from model-based software development for single-core to multi-core. This is achieved by evolving the Rubus Component Model to capture explicit concepts for multi-core and parallel hardware and for expressing variable criticality of software functions. The paper illustrates these contributions through an industrial application in the vehicular domain.
Content may be subject to copyright.
Software and Systems Modeling (2020) 19:1283–1302
https://doi.org/10.1007/s10270-020-00795-5
SPECIAL SECTION PAPER
Modelling multi-criticality vehicular software systems: evolution of an
industrial component model
Alessio Bucaioni1,2 ·Saad Mubeen1,2 ·Federico Ciccozzi1·Antonio Cicchetti1·Mikael Sjödin1
Received: 31 January 2019 / Accepted: 31 March 2020 / Published online: 30 April 2020
© The Author(s) 2020
Abstract
Software in modern vehicles consists of multi-criticality functions, where a function can be safety-critical with stringent real-
time requirements, less critical from the vehicle operation perspective, but still with real-time requirements, or not critical at
all. Next-generation autonomous vehicles will require higher computational power to run multi-criticality functions and such
a power can only be provided by parallel computing platforms such as multi-core architectures. However, current model-based
software development solutions and related modelling languages have not been designed to effectively deal with challenges
specific of multi-core, such as core-interdependency and controlled allocation of software to hardware. In this paper, we report
on the evolution of the Rubus Component Model for the modelling, analysis, and development of vehicular software systems
with multi-criticality for deployment on multi-core platforms. Our goal is to provide a lightweight and technology-preserving
transition from model-based software development for single-core to multi-core. This is achieved by evolving the Rubus
Component Model to capture explicit concepts for multi-core and parallel hardware and for expressing variable criticality of
software functions. The paper illustrates these contributions through an industrial application in the vehicular domain.
Keywords Model-based engineering ·Metamodelling ·Single-core ·Multi-core ·Multi-criticality ·Vehicular embedded
systems ·Real-time systems
1 Introduction
Software has become the heart of modern systems across
most domains and is enhancing, sometimes even replacing,
an ever larger number of mechanical and electrical parts.
Communicated by A. Pierantonio, A. Anjorin, S. Trujillo, and H.
Espinoza.
BAlessio Bucaioni
alessio.bucaioni@mdh.se;
alessio.bucaioni@arcticus-systems.com
Saad Mubeen
saad.mubeen@mdh.se; saad.mubeen@arcticus-systems.com
Federico Ciccozzi
federico.ciccozzi@mdh.se
Antonio Cicchetti
antonio.cicchetti@mdh.se
Mikael Sjödin
mikael.sjodin@mdh.se
1School of Innovation, Design and Engineering, Mälardalen
University, Västerås, Sweden
2Arcticus Systems AB, Järfälla, Sweden
The automotive industry, for instance, has experienced a dra-
matic increment of software in vehicles. A modern car is a
software-intensive system, while historically vehicles have
been considered to be mechanics-intensive [1].Thesameis
happening in other domains, such as, for example, aerospace,
automation, and robotics.
In our research, we target vehicular applications, where
multiple networks, consisting of electronic control units
(ECUs), sensors, and actuators whose most value-added
functionalities are realised by software. An example is the
throttle control system, implemented now in these terms
and replacing the old-fashioned mechanical linkage between
the gas pedal and the throttle valve. Besides single specific
control functionalities, the current trend in automotive is to
empower software to steer vehicles, break, and in general
to control complex vehicle behaviours. While most current
vehicular systems only leverage single-core ECUs, to be able
to provide suitable computational power to such a complex
software, the trend is to switch to ECUs with multi-core
microprocessors.
Shifting to multi-core impacts the way vehicular software
is designed, analysed and developed. Current model-based
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1284 A. Bucaioni et al.
solutions, specifically tailored to single-core, are hardly
reusable when dealing with challenges specific to multi-
core [2], such as core-interdependency and allocation of
parallel software to hardware. The latter is further compli-
cated by the so-called multi-criticality problem. Vehicular
software typically consists of functions with different crit-
icality levels: some are safety-critical with stringent real-
time requirements (e.g. airbag deployment), some are not
safety-critical although with real-time requirements (e.g.
speedometer), others are not critical (e.g. infotainment). In
this landscape, a challenge is to design and develop multi-
criticality software and allocate it to hardware in a reliable
and cost-effective manner.
We have long been working on enhancing Rubus [3], a
commercial model-based approach and modelling language
for vehicular single-core systems, to address multi-core plat-
forms with the intent of not disrupting the existing vehicular
software-assets developed in the vehicular industry. Such
core assets include:
own legacy, up to 90% of the software in a new vehicle
release can be reused from previous releases [4];
supplier legacy Original Equipment Manufacturers
(OEMs) have decennial contracts with Tier-N suppliers
and changes to assets shall not affect them, and
certified run-time support,1important since model-based
solutions rely on certified development environments and
real-time operating systems (RTOS) [5] and, typically,
the certification process adds a development cost over-
head between 25 and 100% [6].
Our goal was to evolve the Rubus Component Model
(RCM) [7], core of the Rubus approach, to support multi-core
in modelling multi-criticality vehicular software systems. In
this paper, we describe the process that we followed and show
the results of our effort. Moreover, we discuss key lessons we
learnt from this effort and that could help other technology
providers facing similar transitions.
The remainder of the paper is structured as follows. Sec-
tion 2describes the specific contributions of this work and
put them in relation with the authors’ previous works. Sec-
tion 3motivates the selection and evolution of RCM, the
background as well as the comparison between existing
related approaches documented in the literature and our solu-
tion. Section 4describes the evolution of RCM. Section 5
discusses the application of the proposed solution to an indus-
trial application in three different configurations. Section 6
discusses our contributions from a more generic viewpoint
1Rubus RTOS is certified according to the ISO 26262 safety standard,
whereas the certification of the Rubus-ICE development environment
is undergoing.
while Sect. 7concludes the paper with final remarks and
intended future work.
2 Contribution
Although there are several modelling languages used in the
vehicular domain such as, for example, AUTOSAR [8], Pro-
Com [9], COMDES [10], AADL [11], we focus on RCM
and its extension for multi-core due to the following rea-
sons. Thanks to its statically synthesised communication as
well as its predictable and fine-grained execution model,
RCM allows overcoming the issues related to predictabil-
ity [12]. Moreover, RCM uses pipe-and-filter2communica-
tion and distinguishes between the control and data flows
among its software components; this communication mech-
anism resembles the sender receiver communication in the
AUTOSAR standard [8]. In [13], we showed how these fea-
tures contributed to enable early timing verification of the
modelled system, e.g. by supporting end-to-end timing analy-
sis [14] of software architectures of the system at early stages
during the development. Lastly, the automatically generated
footprint of the executable image of the system is consistently
smaller than for other modelling languages [13]. Whereas our
work focuses on RCM, we believe that the evolution prob-
lems that we faced are commonly emerging in the transition
of similar languages towards the support of multi-core plat-
forms.
Originally, RCM was aimed at providing support for the
development of distributed real-time systems through the
specification of re-usable units of software (i.e. software
components). However, RCM did not feature any form of
automation. In order to achieve a full-fledged model-based
approach, in [15] we reverse-engineered the RCM specifi-
cation in order to express it in a more canonical form, i.e.
through a metamodel, called RubusMM. RubusMM included
concepts for expressing software architectures and concepts
for describing timing information of vehicular single-core
applications. In [16], we evolved RubusMM to entail con-
cepts for modelling vehicular applications on multi-core.
In this work, we report on the evolution of RubusMM,
the modelling language core of the Rubus approach, to sup-
port multi-core in modelling software with multi-criticality
for vehicular embedded systems. This evolution represents
a crucial step in transitioning from single-core to multi-core
without disrupting the current vehicular software-assets. In
particular, the contribution is twofold.
Contribution 1 (C1) We revolve the Rubus modelling lan-
guage so as to enable the prescription of the structure of
2The pipe-and-filter communication mechanism is used by many
software component models in the vehicular domain [12], e.g.
COMDES [10], ProCom [9].
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1285
multi-criticality software systems to be deployed on single
core and multi-core as well as on mixed architectures.3
Contribution 2 (C2) We ensure backward compatibility with
legacy software systems modelled with RubusMM and do
not cause any modification to the Rubus runtime layer, the
certified Rubus Kernel.
While evolving RubusMM, we built upon the previous
extensions introduced in [16], focusing on introducing con-
cepts for modelling multi-criticality vehicular systems (C1,
C2). More specifically, we answered to the following needs:
Improve separation of concerns Separation of concerns is
a long-known practice (first advocated by Dijkstra [17]),
which aims at separating different aspects of software
for improving separate reasoning and focused specifi-
cation. Such a practice has been a pivotal aspect in the
definition of modern (modelling) languages especially
for those supporting the component-based design pat-
tern [18]. Nevertheless, separation of concerns has been
sometimes neglected in favour of more pragmatic choices
when defining languages. This is especially true for lan-
guages having a strong industrial connotation, as in the
case of RubusMM, which, prior to this extension, was
fairly monolithic, blending software, hardware, and anal-
ysis aspects together. Thereby, in order to make the
language more flexible to evolutions, such as the one
presented in this paper, a first step was to enhance, or
rather include, separation of concerns at metamodelling
level in RubusMM.
Extend timing modelling concepts Real-time embedded
systems require evidence that their output will be deliv-
ered at the time that is suitable for the environment they
interact with. Schedulability analysis is an a-priori tim-
ing analysis technique which ascertains whether each
function in the system is going to meet its timing require-
ments. The majority of existing timing analyses are used
at an abstraction level that is close to the system imple-
mentation (e.g. code).
The language needed modelling support that was expres-
sive enough to allow the timing analysis of software
architectures at a higher level of abstraction (i.e. mod-
els).
Extend hardware modelling concepts The language only
allowed modelling of single-core CPU-based hardware.
Therefore, we needed to provide the structural constructs
for describing the multi-core, even heterogeneous, hard-
ware architectures. This includes general information
about the hardware (for example: partitions, number
3With respect to C1, the RubusMM presented in [16] did not provide
support for multi-criticality software systems.
of cores, etc.) as well as relationships among hard-
ware elements (for example, containment relations, etc.).
To ensure compatibility with the previous RubusMM
versions and back-compatibility of legacy models, we
needed to take specific countermeasures especially when
extending hardware modelling concepts.
Extend software modelling concepts The ISO 26262 [5]
safety standard defines the Automotive Safety Integrity
Level (ASIL) as a risk classification system for the func-
tional safety of road vehicles. Accordingly, vehicular
software functions are categorised with respect to the
risks associated with their failure. There are four ASILs
identified by ISO 26262: A, B, C, and D, where ASIL A
represents the lowest degree (lowest criticality level) and
ASIL D represents the highest degree (highest criticality
level) of automotive hazard. In order to support the mod-
elling and execution of software functions with different
criticality levels on the same core, we use partitions to
logically isolate the software functions with respect to
their criticality levels. Partitioning is a proven method
for implementing the logical isolation of software on the
same core. A core can have a minimum of one and a
maximum of five partitions, where each partition hosts
software with the same criticality level that corresponds
to ASIL A, B, C, D or non-critical. Note that there are
several ways to implement the partitions, e.g. assigning
distinct runtime priorities to each partition or assigning a
dedicated execution budget to each partition with respect
to its criticality level. In this work, we assume the priority-
based implementation.
3 Background and related work
3.1 The Rubus concept
Rubus is developed by Arcticus Systems4in collabora-
tion with Mälardalen University and other academic and
industrial partners [19]. The Rubus concept is based around
the RCM [7] and its development environment Rubus-ICE
(Integrated Component development Environment), which
includes modeling tools, code generators, analysis tools and
run-time infrastructure. Rubus also provides a real-time oper-
ating system which has been certified to the highest ASIL
level according to the ISO 26262 safety standard. The over-
all goal of Rubus is to be aggressively resource-efficient and
to provide means for developing predictable and analyzable
control functions in resource-constrained embedded systems.
RCM and Rubus tools have been used in the vehicle industry
for over 25 years by several OEMs and Tier-1 companies (e.g.
4https://www.arcticus-systems.com
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1286 A. Bucaioni et al.
Fig. 1 Example of a software architecture modelled in RCM
Volvo Construction Equipment, BAE Systems Hägglunds,
Hoerbiger and Knorr Bremse) for the software development
of real-time embedded systems.
3.1.1 The Rubus component model (RCM)
The purpose of RCM is to express the infrastructure for soft-
ware functions. In RCM, a software circuit (SWC) is the
lowest-level hierarchical element and its purpose is to encap-
sulate software functions. An SWC can be seen as a type, or
a class that can be instantiated an arbitrary number of times.
The interaction between the SWCs is clearly separated in
terms of data and control flows for facilitating the definition
of the control specification, typical of real-time embedded
systems, and interactions. Hence, the SWCs interact with
each other via data and control ports, separately. Data ports
used for modelling data communication while control ports
are used for modelling triggering conditions. One impor-
tant principle in RCM is to separate functional code from
the infrastructure implementing the execution model. This
allows visualising explicit synchronisation and data access
at the modelling level, distinctively. Furthermore, this prin-
ciple facilitates the analysis and reuse of SWCs in different
contexts (an SWC has no knowledge how it connects to other
components). The execution semantics of an SWC are as fol-
lows:
1. Upon receiving a trigger signal on the trigger input port,
read data on all data input ports;
2. Execute the encapsulated software function;
3. Write data to all data output ports; and
4. Activate the trigger output port.
An example software architecture of a single-node system
modelled with RCM, depicted in Fig. 1, shows how compo-
nents interact with external events and actuators with respect
to both data and triggering. The figure also shows the inter-
nal structure of one of the SWCs, which consists of one or
more behaviour and one interface that contains all the ports.
In RCM a Behaviour element acts as a root container for
the behavioural model or code. Hence, such an element can
contain either software code (e.g. C) or an executable model
(e.g. Simulink).
3.1.2 The Rubus analysis framework
RCM allows expressing timing requirements and properties
of the software architecture. For example, it is possible to
associate real-time requirements from a generated event and
an arbitrary output trigger along the chain of SWCs. These
requirements are expressed by means of timing constraints.
All timing constraints that are part of the timing model in the
AUTOSAR standard are included in RCM [13]. Moreover,
the designer can express real-time properties of SWCs, such
as worst-case, best-case and average-case execution times
as well as the stack usage. The scheduler will take these
real-time constraints into consideration when producing a
schedule. For event-triggered SWCs, response-time calcu-
lations are performed and compared to the corresponding
timing requirements. The analysis engines support various
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1287
types of timing analysis that include response-time analysis
and end-to-end data propagation delay analysis [20].
3.1.3 The Rubus runtime framework
The SWCs in the resulting software architecture are mapped
to runtime entities called tasks. Each external event trigger
defines a task and SWCs connected through the chain of
triggered SWCs are allocated to the corresponding task. All
SWC chains that are triggered by periodic clocks are allo-
cated to an automatically generated static schedule that fulfils
the precedence order and timing requirements. Within these
chains, the inter-SWC communication is highly optimised to
use the most efficient means of communication possible for
each communication link. The mapping of SWCs to tasks
and generation of the schedule can be optimised to minimise
response times for different types of tasks or memory usage.
The run-time system executes all tasks on a shared stack,
thus eliminating the need for static allocation of stack mem-
ory to each individual task. This optimisation results in a
small runtime footprint of the software architecture.
3.1.4 The Rubus multi-core hypervisor
The Rubus multi-core hypervisor uses resource isolation
techniques [21] for arbitration of intra- and inter-core shared
resources. These isolation techniques are commonly used
in many application domains to simplify and partition the
system resources in time and space, e.g. the Avionics Appli-
cation Standard Software Interface ARINC 653 [22]uses
these techniques [23,24]. The Rubus hypervisor implements
the Time-Division Multiple Access (TDMA) protocol to
arbitrate the shared system bus among the cores [25]. Simi-
larly, memory partitioning techniques are used to isolate the
shared memories, including L3 cache and RAM among the
cores [26]. Isolation techniques enable cores, as well as par-
titions within those cores, to become virtually independent
from other cores and their partitions. In other words, each par-
tition can be seen as a single-core processor equivalent with
dedicated system resources (although with reduced capacity
which is equivalent to the allotted size of shared memory
and bandwidth of the system bus). One notable advantage of
the single-core processor equivalent model is that the over-
all system becomes simple to model, i.e. there is no need to
explicitly model memories, I/Os and other shared resources
in the software architecture.
3.2 Related work
In this section, we survey the principal strands of research
that relate to the work we present in this paper. In Sect. 4
we use these lines of research for categorising the proposed
extensions, and similarly in Sect. 6we use them to discuss
strengths and limitations of this work.
3.2.1 Enhance separation of concerns
Numerous research efforts,5AMALTHEA/APP4MC,6
CHESS [27], DREAMS [28], MultiPARTES [29] address the
design of multi-criticality embedded real-time systems in a
similar way to what is proposed in this article. In particular,
they also propose the separation of concerns when dealing
with software, hardware, and allocation modelling, that is
indeed an implicit consequence of obeying to safety stan-
dards. Nonetheless, typically these solutions aim to be very
generic in order to support multiple application domains,
hence not only automotive but also industrial automation,
avionics, and so forth. On the one hand, this generality
makes the approaches more malleable, e.g. in case of long-
lasting maintenance and evolution of existing applications.
On the other hand, the price to pay is the inherent com-
plexity of eliciting and specifying all the details such that
the tooling support would work as expected (e.g. valida-
tion checks, generation of artefacts, etc.). In this respect, a
domain-specific approach like the one we propose embeds
most of the automotive systems characteristics in the lan-
guage and surrounding tooling, relieving the users from the
burden of specifying all the details. However, major techni-
cal updates (notably the introduction of multi-core platforms)
would typically require an update of the language, tooling,
and existing models (see for instance the work in [30] about
consequences of AUTOSAR metamodel evolutions).
3.2.2 Extend timing modelling
There exists a number of languages that support modelling
of timing properties and requirements in vehicular embed-
ded software systems. TIMMO [31] is an industrial initiative
to provide AUTOSAR [32] with a timing model and it is
based on a language called the Timing Augmented Descrip-
tion Language (TADL) [33] and inspired by MARTE [34].
TADL is redefined and released in the TADL2 [35] specifi-
cation of the TIMMO-2-USE project [36]. There are several
other approaches from academia like COMDES-II [10] and
ProCom [9]. Most of these initiatives lack the support for
expressing low-level details at the higher levels such as link-
ing information in distributed chains. This information is
necessary to extract the end-to-end timing information from
the software architecture to perform its end-to-end timing
analysis [20]. Moreover, no support is provided for extracting
this information from the software architectures of these sys-
tems. Most of the above cited languages such as AUTOSAR,
5https://af3.fortiss.org
6http://www.amalthea-project.org
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1288 A. Bucaioni et al.
ProCom, COMDES and CORBA [37] support modelling of
on board real-time network communication. However, most
of them allow modelling of only low-bandwidth real-time on-
board networks, e.g. CAN, while there are very few works
that support modelling of high-bandwidth real-time on-board
networks that are based on, e.g. switched ethernet. The work
in [38] is one of such works which provides support for mod-
elling of switched Ethernet on-board networks. AUTOSAR,
complemented by the SymTA/S tool, facilitates modelling
of Ethernet, but lacks support for modelling Time Sensitive
Networking (TSN) network. In [39], the authors present a
work in progress for developing an approach to configure
TSN network and verify its configuration.
3.2.3 Extend hardware modelling concepts
There exists a large body of work on multi-criticality systems
for single-core systems. The difficulty of realising multi-
criticality systems on multi-core is the management of shared
resources, which in general makes the timing behaviour of the
system very difficult to predict. There exist two different def-
initions and underlying models of multi-criticality systems
in the real-time embedded systems domain. The first model
is based on Vestal’s work, where different criticality levels
are associated to individual software components (at design
time) or corresponding tasks (at runtime) [40]. Whereas, the
second model associates a unique criticality level to the com-
plete application and not to individual software components
or tasks within the application. This latter model complies
with various standards such as the functional safety stan-
dard for road vehicles ISO 26262 [5] and the aerospace
standard DO-178C [41]. These standards also prescribe that
the criticality level of an application shall be set as its most
critical sub-function, unless time and memory independence
between sub-functions is demonstrated. In practice, devel-
opment efforts tend to take the latter path (i.e. implementing
and demonstrating independence), since in general certifying
the whole application for the highest criticality would be pro-
hibitively expensive [42]. In this work, we extend RCM with
support for multi-criticality systems according to the model
in [43]. A complete discussion of the state of the art on multi-
criticality systems goes beyond the scope of this article, and
the interested reader is referred to [44,45]. Here it is worth
noting that a body of literature has been devoted to schedul-
ing solutions that are able to maximise resources utilisation
while preserving the timing correctness of system execution,
especially for the Vestal’s model of multi-criticality [40].
Vehicular software has to obey safety standards like ISO
26262 [5], therefore the notion of criticality considered in this
article conforms to the standards, as clarified above. In partic-
ular, for the approach proposed in this article the development
process relies on a hypervisor mechanism (e.g. ARINC 653
hypervisor [23]) provided by the underlying runtime envi-
ronment, i.e. time and memory separation between logical
partitions are guaranteed according to a software layer. In this
way, software functions can be grouped according to their
criticality level and deployed on partitions in a consistent
manner, while the runtime guarantees that each partition can
be analysed in isolation for certification purposes. Moreover,
the correctness of design models with respect to alloca-
tion choices is preserved by language constraints, such that
any model including heterogeneous allocations, i.e. sub-
functions with different criticality levels allocated to the same
partition, would make model validation checks to fail.
There exist other hypervisor/virtualisation-based solu-
tions in the literature, like for example the one presented
in [29], that is based on the XtratuM virtualisation layer [46].
Other approaches that leverage hardware features to ensure
space and time separation required by multi-criticality sys-
tems. Notably, in [42] the authors illustrate the safety
argumentation for an automotive case study based on the
AURIX processor family. Those concerns however fall out-
side of the scope of this paper, since its primary goal is to
spare the need to re-certify the Rubus kernel.
3.2.4 Extend software architectural modelling
Some of the mentioned approaches like CHESS [27],
DREAMS [28] and MultiPARTES [29] provide also design/
deployment/space exploration (DSE) features, that is they
support the automatic synthesis of allocation and schedul-
ing configurations such that multi-criticality and other safety
constraints are obeyed [47,48]. Even though in this article
we consider the allocation as a manual activity, the language
expressiveness does not prevent the development of DSE
mechanisms to automatically derive allocation alternatives.
Indeed, in our previous works we have already proposed
model transformations able to perform DSE to generate
correct timing configurations for the system under develop-
ment [49].
EAST-ADL [50] is an architecture description language
devoted to the specification of automotive electronic systems.
To cope with vehicular systems’ complexity, EAST-ADL
leverages a multi-layer approach, where each layer describes
the system at a different abstraction level and from a dif-
ferent perspective. In particular, EAST-ADL defines the
vehicle, analysis, design, implementation, and operational
layers, and each layer includes engineering information like
requirements, vehicle features and functions, variability, soft-
ware and hardware components, and communication. The
implementation layer is usually delegated to domain-specific
languages (DSL), notably AUTOSAR, RCM, and so forth.
Therefore, the work described in this article can be con-
sidered as complementary to EAST-ADL. Indeed, we have
already shown in [51,52] how to employ model transforma-
tions to close the abstraction gaps between EAST-ADL and
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1289
the DSL used at implementation level (namely RCM) and
to anticipate timing analysis at the EAST-ADL design level.
This work furthers the same front of research, introducing
modelling elements for handling multi-core platforms and
multi-criticality issues.
Besides automotive-specific modelling technologies, there
exists a plethora of general-purpose approaches that could
be used to complement the implementation level DSLs like
AUTOSAR and RCM. In general those approaches use
the UML language and its profiles MARTE [34] and/or
SysML [53].
AADL [11] was conceived as an architecture description
language for the avionics domain, but it is being increas-
ingly used for modelling embedded systems in general. When
compared to RCM, AADL also provides multi-core support
and a clear separation of concerns between software and
hardware elements. However, AADL adopts a lower level
of abstraction approach for software architecture modelling,
where typical elements are, e.g. Processes and Threads.
VERTAF/multi-core is a UML/SysML-based framework
for the development of multi-core software [54].
VERTAF/Multi-core proposes UML class diagrams, timed
state machines, and sequence diagrams as the modelling
instruments to describe multi-core software systems. The
viability of the design with respect to schedulability and
conformance to the specifications is verified automatically
through model transformations. In particular, the transfor-
mations generate opportune extensions of the input models
to enable the analyses mentioned earlier. The UML pro-
file MARTE provides extensive support for the design of
multi-core systems. Notably, in [2] the authors provide a
detailed description of the software system architecture to
generate code and perform timing verification through sim-
ulation. In particular, the software components modelled in
UML are complemented with hardware and software to hard-
ware allocation specifications by means of MARTE. Instead,
in [55] the authors propose to employ MARTE for system
development of component-based systems: MARTE mod-
els describing the system are completed with allocation of
components information through automated code genera-
tion. GASPARD [56] is a MARTE-based framework for the
design and implementation of (massive) parallel embedded
systems. MARTE design models are exploited as source to
automatically generate implementation alternatives, giving
place to design space exploration. The framework also sup-
ports code generation for formal verification, simulation and
hardware synthesis. On a similar line of research, the COM-
PLEX framework [57] leverages MARTE models, describing
embedded systems, to perform design space exploration in
order to derive corresponding architectural solutions. All the
above-mentioned approaches are mainly devoted to optimi-
sation of the designed system architectures, e.g. to maximise
parallel execution, while in general safety/certification issues
are not taken into account.
4 Evolving the Rubus component model
In this section, we describe the evolution of RubusMM
(the Rubus metamodel formalising its component model,
RCM) for modelling multi-criticality vehicle software for
multi-core. The evolution entailed adding, extending and
modifying modelling concepts and formalising the evolu-
tion by means of metamodelling. We compare the evolved
RubusMM with its previous definition, given in [15], high-
lighting differences and commonalities.
4.1 Improving separation of concerns
We introduced packages for ensuring a better separation
of concerns, improving the understandability of the meta-
model, and enhancing its extensibility. The RubusMM
packages involved in the evolution are RCM_COMMON,
RCM_HW and RCM_SW, where RCM_HW contains the
elements for modelling the hardware platform, RCM_SW
contains the elements for modelling the software architecture
and RCM_COMMON contains elements that are common
to multiple packages, respectively. Prior to this evolution,
RubusMM did not feature any package.7We removed the
structural containment occurring between hardware and soft-
ware elements, too. More details on this enhancement come
in the following sections.
4.2 Extending timing modelling concepts
System represents the system under development. It inherits
from the abstract metaclass NamedElement, which provides
two attributes: name and ID. Such an inheritance is com-
mon to all the elements in RubusMM. We extended System
with the reference timingConstraint. The addition of the ref-
erence timingConstraint on the element System as well as
on other elements enables the specification of various tim-
ing requirements on these elements and the verification of
the timing requirements on the software architectures using
state-of-the-art timing analysis techniques [58].8Further-
more, the reference timingConstraint is pivotal for the design
space generation technique described in [51]. Without this
extension, it would not be possible to leverage the aforemen-
7The complete explanation of RubusMM is not in the scope of this
work. The interested reader may refer to [15].
8TimingConstraint and other elements from different RubusMM pack-
ages are not part of this extension. However, they are put in relation to
this extension as they contribute to a holistic view of the language and
its peculiarities.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1290 A. Bucaioni et al.
Fig. 2 Fragment of the RCM_HW package for modelling the hardware platform
tioned techniques at system level. We extended RubusMM
with Core and Partition elements (and related references and
attributes) so the language could support the design and tim-
ing analysis of multi-core applications.
4.3 Extending hardware modelling concepts
Figure 2shows a fragment of RubusMM containing elements
from RCM_HW for modelling the hardware platform. One
important principle driving the RubusMM evolution with
respect to the hardware platforms modelling is that we aimed
at introducing the minimum number of hardware elements
that are crucial for the allocation of software to hardware
and for modelling and extracting the timing information to
support the timing analysis engines.
System contains one Network, one or more Targ e t ele-
ments, and one or more Application elements. A Network
element models all the messages exchanged among the Tar-
get elements and has two attributes, protocol and speed,
which specify the protocol (e.g. Controlled Area Network
(CAN) [59]) and the speed of the network in Kbit/s, respec-
tively.
Targ e t is a hardware-specific element which represents a
processor architecture. It has been extended with the refer-
ences timingConstraint,portIO, and portNetwork.Asforthe
System element, the reference timingConstraint enables the
specification of timing constraints, occurrences and events
used for timing verification (at Targ e t level). portIO and
portNetwork model the peripherals and the inter-target com-
munication, respectively.
In the previous definition of RubusMM, Target contained
Mode, acting as a container for the software application.
However, such a containment relation was too restrictive
for modelling multi-criticality applications on multi-core.
In fact, the containment relation between Targ e t and Mode
prescribed that software elements (represented by Mode
elements) were structurally contained by hardware (repre-
sented by Targ e t elements). Although not providing a clear
separation between software and hardware, this structural
containment suited the single-core case, since allocation of
software to hardware was not variably split across different
cores. Modelling for multi-criticality software on multi-core
demands more flexibility, since allocation of software to
hardware is a variability point that can be affected by the
software criticality levels and it can hardly be represented by
a structural containment.
4.3.1 Ensuring backward compatibility with legacy models
In order to provide such a flexibility while ensuring back-
ward compatibility with legacy RubusMM models, we have
modified the existing hierarchy as follows. We have added
the metaclasses TargetLegacy and Targ e t N ew, both inheriting
from the abstract metaclass Targ e t .TargetLegacy represents
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1291
a legacy (single-core) processor and it contains one or more
Mode elements. This containment is specified through the
reference mode.Targ e t N ew represents a single- or multi-
core processor and contains one or more Core elements,
which in turn can contain Partition elements. Targ e t New,
Core and Partition elements inherit from the abstract meta-
class Allocator, representing hardware elements to which
software elements, represented by the metaclass Allocatable,
can be allocated. The metaclasses Allocator and Allocatable,
together with the reference isAllocated, provide the flexible
mechanism for the allocation of software to hardware that
we needed, without any structural containment.
4.3.2 Providing support for multi-core hardware modelling
The metaclass Targ e t provides the following attributes:
speed, which specifies its speed in MHz, and type, which
specifies whether it is a physical or a simulated target. A
simulated target represents the simulation of the actual tar-
get processor in a host environment such as Windows or
Linux. Both TargetLegacy and Targ e t N ew inherit the speed
and type attributes. Moreover, Targ e t N e w provides additional
multi-core specific attributes. numberOfCores specifies the
number of cores composing the Targ e t New, and it is used by
the model-based timing analysis and to automatically allo-
cate software to hardware. The reference core links Core
elements to their respective Tar ge t N e w elements.
Core may contain Partition elements. The attribute num-
berOfPartitions specifies the number of partitions within a
Core and the reference partition links them to the Core ele-
ments. Partition elements represent a logical division of a
core into multiple sets of resources so that each Partition
element can operate independently. In other words, the Par-
tition element isolates one part of software from the other
in both time and space. Isolation in time means that each
partition gets a reserved share of the core processing time
for the execution of the software allocated to it. Isolation in
space means that the memory available to each core is divided
among its partitions. Within RubusMM, any inter-partition
interference is prevented by using memory protection mech-
anisms. As discussed above, the isolation in time and space
is supported by the Rubus multi-core hypervisor by means
of resource-isolation techniques [21].
Targ e t ,TargetLegacy,Tar g e t N e w ,Core,Partition,Allo-
cator,Allocatable, as well as their attributes and related
references were not part of the previous RubusMM def-
inition [52]. It is important to note that the modelling
elements describing multi-core processors could have been
introduced without modifying the original structural contain-
ment. However, this choice would have limited the usability
and flexibility of RubusMM as the allocation choices could
be made early in the development process when relevant
information may not be available. Besides, the allocation
mechanism introduced in RubusMM is common in many
automotive domain-specific modelling languages such as
EAST-ADL, AUTOSAR.
4.4 Extending software architectural modelling
concepts
Figure 3shows a fragment of the RubusMM containing
elements from the RCM_SW and the RCM_COMMON pack-
ages for modelling the software architecture.
4.4.1 Enforcing correctness of criticality-driven allocation of
SW to HW
Within RubusMM, Application models a piece of software
implementing a dedicated functionality, e.g. brake-by-wire.
Application has one attribute, criticalityLevel and contains
one or more Mode elements. This containment is specified
through the reference mode.criticalityLevel specifies the
level of safety criticality according to the ISO 26262 auto-
motive safety standard. The ISO 26262 standard has four
levels of criticality (A to D) where A is the lowest criticality
level, whereas D is the highest criticality level (the Rubus
Kernel supports and is certified for all of them). Application
and criticalityLevel along with the aforementioned allocation
mechanism are pivotal in modelling multi-criticality software
on multi-core, where software applications with different
criticality levels cannot be allocated together on the same
partition. In order to prevent such a situation, we enriched
RubusMM with a structural constraint specified by means
of the Object Constraint Language (OCL)9as an invariant
of Partition elements. Listing 1 shows the pseudo-code for
such a constraint.
1FOR each application:: Application allocated to
partition:: Partition
2criticality.add( application.
criticalityLevel);
3
4IF criticality.size () <=1 THEN
5True
6ELSE
7False
8}
Listing 1 Eclipse OCL constraint avoiding that no Application elements
with different criticality levels are allocated on the same Partition
element.
For each Partition element, the constraint retrieves all its
allocated Application elements. Their criticalityLevel values
are collected into a set. If the size of the set is grater than 1,
the constraints would return the logical value false which, in
turns, will raise a validation error.
9https://projects.eclipse.org/projects/modeling.mdt.ocl
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1292 A. Bucaioni et al.
Fig. 3 Fragment of the RCM_SW package for modelling the software architecture
4.4.2 Extending allocability of SW to HW
In RubusMM a software circuit is represented by SWC and
it is the lowest-level hierarchical element that encapsulates
basic software functions. A SWC contains one Interface
which groups all its ports. As RubusMM distinguishes
between the data and control flows, an Interface con-
tainsPortD a t a and Po r t Tr i g elements. The Po r t D ata elements
manage the data communication among SWC deployed on
the same Targ e t .ThePor t Tr i g elements manage the activa-
tion of the SWC elements. A PortN e t w o r k is a port for the
data communication of SWC elements deployed on differ-
ent Targ e t elements. The Po r t D a t a elements of a Core are
referenced to the PortD a t a elements of the SWCs allocated
on that Core. Similarly, the Por t N e t w o rk elements of a Node
are referenced to the PortN e t w o r k elements at SWC level.
An Assembly groups SWC and Assembly elements in a hier-
archical fashion. Its reference timingConstraint enables the
specification of timing constraints, occurrences and events
which are used for timing verification. With respect to the
previous definition, SWC and Assembly have been extended
with the inheritance relation from the abstract metaclass Allo-
catable.AMode groups Assembly and SWC elements and it
is used for modelling a specific configuration of the soft-
ware architecture (e.g. start-up or error mode). The attribute
globalReference serves for creating a reference among all the
Mode elements contributing to the same mode. With respect
to its previous definition, Mode has been extended with the
inheritance relation from the abstract metaclass Allocatable.
The metaclasses Allocatable and Allocator together with the
reference isAllocated enable the specification of the alloca-
tion of software to hardware. More precisely, an Allocatable
element can be deployed to an Allocator element by setting
the isAllocated reference. Application,Allocatable,Alloca-
tor, and related references were not part of the previous
RubusMM definition.
5 Modelling the brake-by-wire application
In this section, we leverage the evolved RubusMM for
modelling the Brake-by-wire (BBW) vehicular applica-
tion, which is an innovative stand-alone braking system
currently deployed in premium electric and hybrid vehi-
cles [60]. In a nutshell, the BBW application replaces the
old-fashioned mechanical linkages and allows controlling
the brakes through electronic means. Figure 4depicts a sim-
plified electrical/electronic (E/E) architecture of the BBW
application featuring an anti-lock braking (ABS) function.
A sensor attached to the brake pedal acquires the signal
that corresponds to the position of the pedal. This signal is
sent to a computational unit which translates it into a brake
torque. For each wheel, a sensor acquires the signal that cor-
responds to the speed of the wheel. The sensed speed is sent
to two computational units. The first unit calculates the indi-
vidual brake torque for each wheel using the sensed speed
and the computed brake torque. The second unit calculates
the speed of the vehicle using the speed of each wheel. The
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1293
Fig. 4 Simplified E/E
architecture of the BBW
application
Fig. 5 RubusMM model representing the software architecture of the BBW application
ABS units use the speed of the vehicle and sensed wheels
brake torques for calculating the optimal brake torque for
each wheel. The actuators on the wheels release the optimal
brake torques avoiding the brakes to lock.
Figure 5shows a RubusMM model depicting the software
architecture of the BBW application. The model consist of
16 software circuits where i) Brake_Pedal models the soft-
ware operating the sensor on the brake pedal, ii) Speed_FR,
Speed_FL,Speed_RR, and Speed_RL model the software
operating the speed sensors on the wheels, iii) Brake_Torque,
Brake_Controller,Speed_Estimator,ABS_FR,ABS_FL,
ABS_RR, and ABS_RL model the software on the compu-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1294 A. Bucaioni et al.
Fig. 6 Serialisation of the BBW application deployed to a unicore
microcontroller
tational units and iv) Brake_FR,Brake_FL,Brake_RR, and
Brake_RL model the software operating the actuators on the
wheels. In order to show how the evolved RubusMM sup-
ports the modelling of multi-criticality software systems on
multi-core (H1), while ensuring backward compatibility with
legacy single-core ones (H2), we describe three different
deployment configurations for the BBW application.
5.1 First configuration: legacy single-core platform
In the first configuration, the BBW application is modelled
as a legacy single-core software system and deployed to
a MPC5744P microcontroller,10 which is a 32-bit unicore
microcontroller designed for vehicular applications. Figure 6
shows the Ecore serialisation of such a configuration.
As the BBW application is modelled as a legacy single-
core system, deployment on the unicore microcontroller
is modelled by the mode containment relation between
TargetLegacy element MPC574xP and Mode element Oper-
ational. Although not providing a clear separation between
software and hardware, this configuration suits the legacy
single-core case as the software cannot be allocated across
different cores (Sect. 4).
10 http://www.nxp.com/assets/documents/data/en/data-sheets/
MPC5744P.pdf
5.2 Second configuration: multi-core platform
In the second configuration, the BBW application is modelled
as a multi-core software system and deployed to an Infineon
SAK-TC299TP-128F300S BB microcontroller,11 which is a
tri-core microcontroller developed for applications with high
demands of performance and safety. Figure 7shows an Ecore
serialisation of this configuration.
As the reader can notice, in this configuration, there is
a clear separation between the hardware and the software
elements of the BBW application. The allocation among
these elements is modelled by means of the isAllocated
reference. We decided to split the allocation of the BBW
Application on the three available cores as follows12 The soft-
ware circuits modelling the sensors, the computation units
and the actuators of the two front wheels (WheelSpeed_FR,
WheelSpeed_FR,Abs_FR,Abs_FL,Brake_FR,Brake_FL)
are allocated to Core 1 of the SAK-TC299TP-128F300S BB
target, as shown by the arrow in the top-left corner of Fig. 7.
Similarly, the SWCs modelling the sensors, the computation
units and the actuators of the two rear wheels (Wheel-
Speed_RR,WheelSpeed_RR,Abs_RR,Abs_RL,Brake_RR,
Brake_RL) are allocated to Core 2 of the SAK-TC299TP-
128F300S BB target. The remaining SWCs modelling the
computational units are allocated to Core 3 of the SAK-
TC299TP-128F300S BB target. As discussed in Sect. 4,the
evolved RubusMM leverages a clearer separation of concerns
as well as an explicit and more flexible allocation mechanism.
For instance, let us suppose that the allocation specified in
Fig. 7does not satisfy a given set of fault-tolerance require-
ments. One way of addressing this issue would be to model
a lockstep configuration of the BBW application where each
core runs a copy of the complete software in parallel. In
order to model a lockstep configuration with the evolved
RubusMM it would be sufficient to change the isAllocated
reference of the BBW Application, only. In particular, the
isAllocated reference of the BBW Application should point
to Core1,Core2 and Core3.13
5.3 Third configuration: multi-criticality on
multi-core platform
In the third configuration, we consider the Proactive Wiper
(PW) vehicular application in addition to the BBW one. We
11 http://www.infineon.com/cms/en/product/microcontroller/32-
bit-tricore-tm-microcontroller/aurix-tm-family/channel.html?
channel=db3a30433727a44301372b2eefbb48d9
12 It is important to note that this allocation is arbitrary hence other,
still valid, allocations are possible.
13 It should be noted that a redundant configuration as the one described
above would require a voting software mechanism to be defined and
allocated. While this is a valid concern, for the sake of verbosity, we
focus on the BBW and its allocation, only.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1295
Fig. 7 Serialisation of the BBW application deployed to a tri-core microcontroller
model these two applications as a multi-core software sys-
tem with different criticality levels and deploy them into the
aforementioned tri-core microcontroller. The PW is a stand-
alone system which uses the information from the vehicle’s
front camera, radar and rain sensor for preventing sudden
water splashes (caused by large vehicles) to give the driver
an unclear view.14 Figure 8depicts a simplified E/E archi-
tecture of the PW application.
A radar positioned on the front of the vehicle acquires
the signal that corresponds to the presence of objects ahead.
Such a signal is used in conjunction with the signal from
the camera for establishing whether these object could be
large vehicles approaching from the opposite direction. A
rain sensor attached to windscreen of the vehicle acquires
the signal that corresponds to the quantity of water that is
raining. This signal, together with the information on the
large vehicles, is sent to a computational unit which decides if
it is necessary to activate the windscreen wipers. Eventually,
the actuators on the wipers will give the driver a clear view.
Figure 9shows the RubusMM model describing the soft-
ware architecture of the PW application. The model consist
14 https://semcon.com/paw/
of 5 software circuits where i) Rain models the software
operating the rain sensor, ii) Radar and Camera model the
software operating the front radar and camera, respectively,
Computation models the software on the computational units
and iv) Wipers models the software operating the actuator
on the windscreen wipers. Figure 10 shows the Ecore seri-
alisation of the model depicting the third configuration. In
this configuration, the System Vehicle is composed of a Tar-
get element (modelling the tri-core microcontroller) and two
Application elements (modelling the BBW and PW applica-
tions). According to the ISO 26262 [5] standard, the BBW
and PW Application elements have different criticality levels
(as shown in Fig. 10). In particular, we assigned the criticality
level Dto the BBW Application element whereas the criti-
cality level Ato the PW Application element.
As applications with different criticality levels cannot be
allocated to the same partition, the Core1 element is parti-
tioned into two Partition elements (Partition1 and Partition2)
and the BBW and PW Application elements are allocated
as follows. For the BBW Application,theWheelSpeed_FR,
WheelSpeed_FL,Abs_FR,Abs_FL,Brake_FR,Brake_FL
software circuits are allocated to Partition 1;the(Wheel-
Speed_RR,WheelSpeed_RL,Abs_RR,Abs_RL,Brake_RR,
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1296 A. Bucaioni et al.
Fig. 8 Simplified E/E
architecture of the PW
application
Fig. 9 RubusMM model representing the software architecture of the PW application
Brake_RL) software circuits are allocated to Core 2 while
the remaining software circuits are allocated to Core 3.The
PW Application is allocated to Partition 2 a shown by the
arrow.
If we would have attempted to allocate the PW Applica-
tion to Partition 1, the OCL contraint described in Sec. 4
would have generated a validation error and prevented us
from allocating applications with different criticality levels
on the same partition.
In this section, we use-cased the BBW application in three
different deployment configurations for describing the appli-
cability of the evolved RubusMM. In the first configuration,
we deployed the BBW application into a single-core micro-
controller for demonstrating the suitability of the evolved
RubusMM for describing legacy vehicular software sys-
tems. In the second configuration, the BBW application was
deployed into a tri-core microcontroller to show how the
evolved RubusMM could support the development of upcom-
ing vehicular software systems on multi-core. Finally, in the
third configuration we considered the PW application in addi-
tion to the BBW one for demonstrating the applicability of
the evolved RubusMM in modelling multi-criticality vehic-
ular software.
We model these two applications as a multi-core software
system with different criticality levels and deploy them into
the aforementioned tri-core microcontroller.
6 Discussion
In this work, we proposed an evolution of the Rubus Compo-
nent Model (RCM), in terms of its metamodel RubusMM, for
developing multi-criticality software systems to be deployed
on single- and multi-core as well as on mixed architectures
(C1). The proposed evolution ensures backward compatibil-
ity with legacy software systems modelled with RubusMM
and does not cause any modification to the Rubus run-time
layer and certified Rubus Kernel (C2). Both of the previ-
ous challenges can be seen as critical preconditions of any
complex software in general: it is, at least economically,
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1297
Fig. 10 Serialisation of the BBW and PW applications deployed to a tri-core microcontroller as multi-criticality system
not affordable to throw away the past history of develop-
ment efforts due to compatibility problems; if (parts of)
the designed product undergoes certification processes, it
is desirable to avoid expensive and long-lasting tool re-
certification issues due to refinements. Since Rubus targets
the vehicular domain, we devote the remainder of this sec-
tion to reason about backward compatibility and avoidance
of re-certification due to the needs conveyed by modelling
multi-criticality systems and corresponding introduced fea-
tures.
Functional safety is paramount in the vehicular domain.
To earn acceptance, solutions like Rubus must provide certi-
fied run-time support, e.g. real-time operating system, along
with modelling languages able to capture all the character-
istics of vehicular applications. In this respect, we extended
RubusMM (the Rubus metamodel formalising its compo-
nent model) according to the virtualisation design option,
as described in [61], which enables the reuse of the certi-
fied Rubus Kernel. The Rubus Kernel is certified according
to the ISO 26262 standard ASIL D while Rubus ICE (i.e.
the development environment supporting Rubus) is undergo-
ing the same certification. On the one hand, the reuse of the
Rubus Kernel makes unnecessary the explicit modelling of
the memory since the mapping of data ports to physical mem-
ory is handled by the kernel itself. On the other hand, it makes
the current definition of RubusMM not suited for approaches
where explicit modelling of the memory is required. More-
over,despite the Rubus Kernel footprint is significantly small,
the virtualised design option increases the overall footprint
of the developed vehicular application since each core or
partition can host a separate instance of the Rubus Kernel.
6.1 Evolution of RubusMM
In the following subsections we discuss our contributions in
evolving RubusMM in terms of the extensions described in
Sect. 4, and summarised against needs in Table 1,alsofrom
a cross-language perspective, in order to potentially support
similar evolution processes of other languages.
Enhance separation of concerns Separation of concerns
is a key aspects of (modelling) languages, especially those
supporting the component-based design pattern [18]. Before
this extension, and due to the fact that the language was
meant to only support one single type of target hardware
platform, RubusMM was fairly monolithic, blending soft-
ware, hardware, and analysis aspects together. This made the
RubusMM definition not easy to understand and thereby hard
to extend. As first step of evolving it, we enforced separation
of concerns by separating metamodelling concepts in three
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1298 A. Bucaioni et al.
Table 1 Summary of features in relation to needs
Need Feature(s) Extension
Enhance separation of concerns We introduced packages and removed structural containment relations See Sect. 4.1
Extend timing modelling We introduced timingConstraint reference for several elements in
RubusMM. We introduced Core and Partition elements (and related
references and attributes)
See Sect. 4.2
Extend hardware modelling concepts We introduced Targ e t ,Ta rg e t N e w,TargetLegacy,Core,Partition,
Allocator elements. We introduced isAllocated reference and the
speed,type and numberOfCores attributes
See Sect. 4.3
Extend software architectural modelling We introduced Application and Allocatable, elements. We introduced
the criticalityLevel attribute and the OCL constraint
See Sect. 4.4
packages. Before to opt for this separation, we attempted to
achieve our evolution goals by re-arranging metaconcepts
using the existing flat structure, but we could not succeed
due to potential circular containments and multiple (invalid)
specialisations of metaconcepts. Without enforcement of
separation of concerns of the original RubusMM modelling
concepts, we could have not been able to provide the subse-
quent extensions nor open up for possible further extensions
(see Sect. 7).
Extend timing modelling concepts In Sect. 2, we pointed
out high-precision timing analysis as one of the main reasons
that made RubusMM appreciated in the vehicular domain and
its evolution for multi-core and multi-criticality compelling.
In this work, we have explicitly addressed the modelling
of timing information, i.e. timing constraints, occurrences
and events at several levels of the structural hierarchy by
means of the reference timingConstraint. This information
is required to perform the timing analysis of the software
architectures of vehicular systems. Besides ensuring full
compatibility with the existing model-based timing anal-
ysis provided by Rubus, this enables the use of the most
recent timing analysis for multi-criticality software systems
on multi-core [44,45]. Without the evolution provided in this
paper, the timing analysis for multi-criticality software sys-
tems on multi-core would not have been possible at different
levels of the structural hierarchy due to the missing structural
and timing information.
Extend hardware modelling concepts The addition of mod-
elling of multi-core hardware architectures was one of the
core extensions being part of the RubusMM evolution. For
providing that, we added the needed metaconcepts without
modifying any existing hierarchical structures (as in the case
of, e.g. Targ e t and Partition) and introduced the new meta-
concepts as leaves in the metamodel hierarchy (as in the case
of, e.g. Core and Partition). Evolution of a language and
the framework supporting it cannot overlook compatibility
with previous versions of the language and the existing arte-
facts conforming to it. The evolution of RubusMM was not
an exception, especially since Rubus is an industrial frame-
work, and thereby the ability to keep compatibility with
legacy models (and related artefacts) was pivotal. In the case
of RubusMM, compatibility issues could arise concerning
legacy models starring the old hardware modelling concept
of single-core processors only. As part of the language evo-
lution, we decided to go for an additive change, by keeping
the old hardware modelling structure and adding the new
concepts in a brand new set of metaconcepts. Both are valid
(mutually exclusive) options for hardware modelling in the
evolved RubusMM. While we were able to approach back-
compatibility in this non-disruptive way due to the rather
simplicity of the involved evolution, in other cases it may
not be possible to do so. In such cases, a valid alternative
could be a semi-automated patching mechanism for guiding
the modeller in importing (and co-evolving) legacy models
to conform to the evolved language.
Extend software modelling concepts Regarding evolution
of software modelling concepts, we introduced a competent
support for modelling software applications with multi-
criticality as well as the possibility to flexibly allocate them
to specific hardware components. The previous RubusMM
version, especially through the hindering structural contain-
ment between Targ e t and Mode, did not allow allocation
of different software components to different cores accord-
ing to their criticality level. We extended RubusMM with
a set of allocation metaconcepts that is more flexible and
provides multiple allocation strategies to the engineer. The
introduced allocation metaconcepts, with embedded variabil-
ity modelling capabilities, can also be leveraged by model
transformations for automatically generating sets of potential
allocation candidates, all in a single model with variability
points discerning different candidates, as we have shown in a
spin-off of this work [62]. It is important to note that, besides
allowing any combination of software applications with spe-
cific criticality levels to be allocated to any core, we provide
an automated validation mechanism to enforce criticality-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1299
safe grouping according to the ISO 26262 automotive safety
standard. More specifically, we do not allow software appli-
cations with different criticality levels to be allocated together
on the same partition.
6.2 Applicability and outlook
We showed the applicability of the extended RubusMM
through the Brake-by-wire application. In particular, we
modelled the functional software architecture of the BBW
application and provided three different deployment config-
urations of varying complexity. In this respect, the functional
software architecture in Fig. 5describes the BBW applica-
tion coming from our industrial partner, Volvo Group. In
the first configuration, we used the extended RubusMM for
modelling a legacy RCM application. In the second config-
uration, we showed the applicability of the evolved RCM in
modelling vehicular software applications on multi-core. It
is worth noting that, despite several allocations of the BBW
software components to the tri-core micro-controller could
have been possible, we showed one of them (Fig. 7) and dis-
cussed the realisation of a lockstep allocation configuration,
only. In fact, our focus was to demonstrate the flexibility of
the evolved RubusMM with respect to allocation strategies
rather than discuss the generation of the whole space of pos-
sible allocations.
The RCM evolution described in this work has paved the
way to the latest release of the Rubus Component Model,
namely RCM V.5, currently used within the commercial
integrated development environment Rubus ICE. What is
more, the challenges and opportunities that arose during this
research work have contributed to the definition of several
collaborative research projects between academia and indus-
try such as Automation in High-performance Cyber Physical
Systems Development (A-CPS)15 and Heterogeneous sys-
tems and software-hardware integration (HERO).16
7 Conclusion and future work
In this work, we discussed the evolution of the Rubus Com-
ponent Model (RCM), in terms of its metamodel RubusMM,
for modelling software systems to be deployed on single-,
multi-core as well as on mixed architectures while ensuring
backward compatibility with legacy RCM software systems
and compliance to the Rubus run-time layer and certi-
fied Rubus Kernel. The proposed evolution enables support
for modelling multi-criticality of software components and
validity checks for their allocation to cores. We considered an
15 http://www.es.mdh.se/projects/520-Automation_in_High_perform
ance_Cyber_Physical_Systems_Development
16 http://www.es.mdh.se/projects/511-HERO
industrial vehicular application to assess the applicability of
the evolved RCM, also in terms of backward compatibility.
One line of future work will investigate how to support
the analysis and verification of vehicular embedded systems
with multi-criticality levels on multi-core with respect to pre-
dictable timing behaviour. To this end, we will investigate
how to adapt the certified Rubus Kernel for providing run-
time support to these systems on multi-core.
In [49], we investigated how to provide automatic support
for the allocation of software to hardware. In particular, we
developed model transformations that, starting from a model
with no modelled allocations and a set of timing constraints,
produced a set of models featuring the set of different allo-
cations of software to hardware optimised for satisfying the
set of timing constraints. Despite the generation of models is
transparent to the engineer and it can be guided through logic
constraints, issues about scalability and performance may
remain open. In this respect, another line of future investiga-
tion encompasses the study of a smarter generation process
which could (i) narrow and cluster the space of the generated
models and (ii) use different non functional properties for
pruning the set of the generated models. In addition, we are
planning to represent the set of generated models by means
of the compact notation presented in [62]. Such a notation
uses modelling with variability for representing a multitude
of models with one single model with variability points.
Due to the terrific data-throughput induced by vehicular
software functions, domain experts are investigating the use
of heterogeneous platforms built of several different com-
putational units (multi-core central processing units, graphic
processing units, etc.) on a single board. In this respect, a
future evolution of RCM will provide support for modelling
and analysis software for these platforms.
Acknowledgements Open access funding provided by Mälardalen
University. The work in this paper has been supported by the Swedish
Knowledge Foundation (KKS) through the MINEStrA, HERO and
DPAC projects and by the Swedish Governmental Agency for Inno-
vation Systems (VINNOVA) through the DESTINE project. We thank
our industrial partners Arcticus Systems and Volvo Construction Equip-
ment, Sweden.
Open Access This article is licensed under a Creative Commons
Attribution 4.0 International License, which permits use, sharing, adap-
tation, distribution and reproduction in any medium or format, as
long as you give appropriate credit to the original author(s) and the
source, provide a link to the Creative Commons licence, and indi-
cate if changes were made. The images or other third party material
in this article are included in the article’s Creative Commons licence,
unless indicated otherwise in a credit line to the material. If material
is not included in the article’s Creative Commons licence and your
intended use is not permitted by statutory regulation or exceeds the
permitted use, you will need to obtain permission directly from the copy-
right holder. To view a copy of this licence, visit http://creativecomm
ons.org/licenses/by/4.0/.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1300 A. Bucaioni et al.
References
1. Charette, R.N.: This car runs on code. IEEE Spectrum 46, (2009)
2. Ciccozzi, F., Seceleanu, T., Corcoran, D., Scholle, D.: UML-based
development of embedded real-time software on multi-core in prac-
tice: lessons learned and future perspectives. IEEE Access 4, (2016)
3. Rubus ICE-Integrated Development Environment, http://www.
arcticus-systems.com, Accessed: September (2019)
4. Thorngren, P.: Keynote talk: experiences from east-adl use. In:
EAST-ADL Open Workshop, Gothenberg (2013)
5. ISO 26262-1:2011: Road Vehicles in Functional Safety, http://
www.iso.org, Accessed: September (2019)
6. Pop, P., Scholle, D., Hansson, H., Widforss, G., Rosqvist, M.: The
SafeCOP ECSEL Project: safe cooperating cyber-physical systems
using wireless communication. In: Euromicro Conference on Dig-
ital System Design (DSD). IEEE (2016)
7. Hänninen, K., Mäki-Turja, J., Sjödin, M., Lindberg, M., Lundbäck,
J., Lundbäck, K.: The rubus component model for resource con-
strained real-time systems. In: 3rd IEEE International Symposium
on Industrial Embedded Systems (2008)
8. The AUTOSAR Consortium, AUTOSAR Techincal Overview,
Version 4.3., http://autosar.org, Accessed: September (2019)
9. Séverine, S., Vulgarakis, A., Bures, T., Carlson, J., Crnkovic, I.:
A component model for control-intensive distributed embedded
systems. In: 11th International Symposium on Component Based
Software Engineering (CBSE). Springer, Berlin (2008)
10. Xu, K., Sierszecki, K., Angelov, C.: COMDES-II: a component-
based framework for generative development of distributed real-
time control systems. In: 13th IEEE International Conference on
Embedded and Real-Time Computing Systems and Applications
(RTCSA) (2007)
11. Feiler, P.H., Gluch, D.P., Hudak, J.J.: The architecture analysis and
design language (AADL): an introduction. Technical report (2006)
12. Mubeen, S., Mäki-Turja, J., Sjödin, M.: Communications-oriented
development of component- based vehicular distributed real-time
embedded systems. J. Syst. Archit. 60, (2014)
13. Mubeen, S., Nolte, T., Sjödin, M., Lundbäck, J., Lundbäck, K.:
Supporting timing analysis of vehicular embedded systems through
the refinement of timing constraints. Softw. Syst. Model. (2019)
14. Feiertag, N., Richter, K., Nordlander, J., Jonsson, J.: A Com-
positional framework for end-to-end path delay calculation of
automotive systems under different path semantics. In: Proceed-
ings of the IEEE Real-Time System Symposium, Workshop on
Compositional Theory and Technology for Real-Time Embedded
Systems (2009)
15. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Mubeen, S., Sjödin, M.: A
metamodel for the rubus component model: extensions for timing
and model transformation from EAST-ADL. J. IEEE Access 5,
(2016)
16. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Mubeen, S., Sjödin, M.:
Technology-preserving transition from single-core to multi-core in
modelling vehicular systems. In: Springer, editor, 13th European
Conference on Modelling Foundations and Applications (2017)
17. Dijkstra, E.W.: On the role of scientific thought. In: Selected Writ-
ings on Computing: A Personal Perspective, p. 60–66. Springer,
Berlin (1982)
18. Crnkovic, I., Larsson, M.: Building Reliable Component-Based
Software Systems. Artech House Inc, Norwood (2002)
19. Mubeen, S., Lawson, H., Lundbäck, J., Gälnander, M., Lundbäck,
K.: Provisioning of predictable embedded software in the vehi-
cle industry: the rubus approach. In: IEEE/ACM 4th International
Workshop on Software Engineering Research and Industrial Prac-
tice (SER IP) (2017)
20. Mubeen, S., Mäki-Turja, J., Sjödin, M.: Support for end-to-end
response-time and delay analysis in the industrial tool suite: Issues,
experiences and a case study. Comput. Sci. Inf. Syst. 10(1), 453–
482 (2013)
21. Fernandez, G., Abella, J., Quiñones, E., Rochange, C., Var-
danega, T., Cazorla, F.J.: Contention in multicore hardware shared
resources: understanding of the state of the art. In: 14th Interna-
tional Workshop on Worst-Case Execution Time Analysis, vol. 39
(2014)
22. ARINC Specification 653P1-2, Avionics Application Software
Standard Interface Part 1 Required Services, http://www.arinc.
com, Accessed: September (2019)
23. VanderLeest, S.H.: Arinc 653 hypervisor. In: 29th Digital Avionics
Systems Conference. IEEE (2010)
24. Gaska, T., Werner, B., Flagg, D.: Applying virtualization to avion-
ics systems the integration challenges. In: 29th Digital Avionics
Systems Conference (2010)
25. Kelter, T., Falk, H., Marwedel, P., Chattopadhyay, S., Roychoud-
hury, A.: Static analysis of multi-core TDMA resource arbitration
delays. Real-Time Syst. 50, (2014)
26. Dasari, D., Nelis, V., Akesson, B.: A framework for memory con-
tention analysis in multi-core platforms. Real-Time Systems 52,
(2016)
27. Cicchetti, A., Ciccozzi, F.,Mazzini, S., Puri, S., Panunzio, M., Zovi,
A., Vardanega, T.: Chess: a model-driven engineering tool environ-
ment for aiding the development of complex industrial systems. In:
Proceedings of the 27th IEEE/ACM International Conference on
Automated Software Engineering. ACM (2012)
28. Barner, S., Diewald, A., Migge, J., Syed, A., Fohler, G., Faugère,
M., Pérez, D.G.: Dreams toolchain: model-driven engineering of
mixed-criticality systems. In: 2017 ACM/IEEE 20th International
Conference on Model Driven Engineering Languages and Systems
(MODELS) (2017)
29. Trujillo, S., Crespo, A., Alonso, A., Pérez, J.: MultiPARTES:Multi-
core partitioning and virtualization for easing the certification of
mixed-criticality systems. Microprocess. Microsyst. 38, (2014)
30. Durisic, D., Staron, M., Tichy, M., Hansson, J.: Evolution of long-
term industrial meta-models: an automotive case study of autosar.
In: 40th EUROMICRO Conference on Software Engineering and
Advanced Applications (2014)
31. TIMMO Methodology, Version 2, Deliverable 7 (2009)
32. SymTA/S for Migration from Single-core to Multi-core ECU-
Software on Infineon Microcontrollers. Electron. Eng. J. (2010)
33. TADL: Timing Augmented Description Language, Version 2,
Deliverable 6, October (2009). The TIMMO Consortium
34. The UML Profile for MARTE: Modeling and Analysis of Real-
Time and Embedded Systems, https://www.omg.org/omgmarte/
Documents/Specifications/08-06-09.pdf, Accessed: September
(2019)
35. Timing Augmented Description Language (TADL2) syntax,
semantics, metamodel Ver. 2, Deliverable 11 (2012)
36. TIMMO-2-USE. https://itea3.org/project/timmo-2-use.html
37. Pavon, J., Tomas, J., Bardout, Y., Hauw, L.-H.: Corba for network
and service management in the tina framework. IEEE Commun.
Mag. 36(3), 72–79 (1998)
38. Bucaioni, M., Mubeen, S., Lundbäck, J., Gålnander, M., Lundbäck,
K.-L., Nolte, T.: Modeling and timing analysis of vehicle functions
distributed over switched ethernet. In: IECON 2017-43rd Annual
Conference of the IEEE Industrial Electronics Society, pp. 8419–
8424. IEEE (2017)
39. Farzaneh, M.H., Shafaei, S., Knoll, A.: Formally verifiable mod-
eling of in-vehicle time-sensitive networks (TSN) based on logic
programming. In: 2016 IEEE Vehicular Networking Conference
(VNC), pp. 1–4. IEEE (2016)
40. Vestal, S.: Preemptive scheduling of multi-criticality systems with
varying degrees of execution time assurance. In: 28th IEEE Inter-
national Real-Time Systems Symposium. IEEE (2007)
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Modelling multi-criticality vehicular software systems: evolution of an industrial… 1301
41. DO-178C Software considerations in airborne systems and equip-
ment certification, https://www.rtca.org/content/publications,
Accessed: September (2019)
42. Agirre, I., Azkarate-askasua, M., Larrucea, A., Pérez, J., Var-
danega, F.J. T., Cazorla, F.J.:. Automotive safety concept definition
for mixed-criticality integration on a cots multicore. In: Computer
Safety, Reliability, and Security (2016)
43. Esper, A., Nélis, G., Nelissen, V., Tovar, E.: How realistic is the
mixed-criticality real-time system model? In: Proceedings of the
23rd International Conference on Real Time and Networks Sys-
tems. ACM (2015)
44. Burns, A., Davis, R.: Mixed Criticality Systems: A Review, eighth
edition. Technical report (2013)
45. Burns, A., Davis Robert, I.: A survey of research into mixed criti-
cality systems. ACM Comput. Surv. 50(6), 82:1–82:37 (2017)
46. Crespo, A., Ripoll, I., Masmano, M.: Partitioned embedded archi-
tecture based on hypervisor: The xtratum approach. In: Proceedings
of the 2010 European Dependable Computing Conference, EDCC
’10. IEEE Computer Society (2010)
47. Voss, S., Schätz, B.: Deployment and scheduling synthesis for
mixed-critical shared-memory applications. In: 20th IEEE Inter-
national Conference and Workshops on Engineering of Computer
Based Systems (ECBS) (2013)
48. Schätz, B., Voss, S., Zverlov, S.: Automating design-space explo-
ration: optimal deployment of automotive sw-components in
an iso26262 context. In: 2015 52nd ACM/EDAC/IEEE Design
Automation Conference (DAC) (2015)
49. Bucaioni, A., Addazi, L., Cicchetti, A., Ciccozzi, F., Eramo, R.,
Mubeen, S., Sjödin, M.: Moves: a model-driven methodology for
vehicular embedded systems. J. IEEE Access 6, 6424–6445 (2018)
50. EAST-ADL Domain Model Specification, Deliverable D4.1.1.,
http://www.atesst.org/home/liblocal/docs/ATESST2_D4.1.1_
EAST-ADL2-Specification_2010-06- 02.pdf, Accessed: Septem-
ber (2019)
51. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Eramo, R., Mubeen, S.,
Sjödin, M.: Anticipating implementation-level timing analysis for
driving design-level decisions in EAST-ADL. In: International
Workshop on Modelling in Automotive Software Engineering
(2015)
52. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Eramo, R., Mubeen, S.,
Sjödin, M.: Exploring timing model extractions at EAST-ADL
design-level using model transformations. In: 12th International
Conference on Information Technology: New Generations
53. Andrianarison, E., Piques, J.D.: Sysml for embedded automotive
systems: a practical approach. In: Conference on Embedded Real
Time Software and Systems. IEEE (2010)
54. Koong, C., Yang, C., Chu, W.: Model-driven multi-core embedded
software design. Multicore Hardware-software Design and Verifi-
cation Techniques (2011)
55. Nicolas, A., Posadas, H., Peñil, P., Villar, E.: Automatic deploy-
ment of component-based embedded systems from UML/MARTE
models using MCAPI. In: Conference on Design of Circuits and
Integrated Circuits (DCIS) (2014)
56. Gamatié, A., Le Beux, S., Piel, É., Ben, Atitallah R., Etien, A.,
Marquet, P., Dekeyser, J.: A model-driven design framework for
massively parallel embedded systems. ACM Trans. Embed. Com-
put. Syst. 10(4), 39 (2011)
57. Herrera, F., Posadas, H., Peñil, P., Villar, E., Ferrero, F., Valencia,
R., Palermo, G.: The COMPLEX methodology for UML/MARTE
Modeling and design space exploration of embedded systems. J.
Syst. Archit. 60, (2014)
58. Mubeen, S., Nolte, T., Lundbäck, J., Gålnander, M., Lundbäck, K.:
Refining timing requirements in extended models of legacy vehic-
ular embedded systems using early end-to-end timing analysis. In:
13th International Conference on Information Technology: New
Generations (2016)
59. ISO 11898-1. Road Vehicles Interchange of Digital Information
Controller Area Network (CAN) for high-speed communication
60. Why Brake-By-Wire Is Coming To Your Car, https://www.
popularmechanics.com/cars/car-technology/a22126727/brake-
by-wire/, Accessed: September (2019)
61. Becker, M., Dasari, D., Nélis, V., Behnam, M., Luís Miguel, P.,
Nolte, T.: Investigation on AUTOSAR-compliant solutions for
many-core architectures. In: 18th Euromicro Conference on Digital
System Design (2015)
62. Bucaioni, A., Cicchetti, A., Ciccozzi, F., Mubeen, S., Sjödin,
M., Pierantonio, A.: Handling uncertainty in automatically gen-
erated implementation models in the automotive domain. In:
42nd Euromicro Conference series on Software Engineering and
Advanced Applications (2016)
Publisher’s Note Springer Nature remains neutral with regard to juris-
dictional claims in published maps and institutional affiliations.
Alessio Bucaioni is an Assis-
tant Professor at Mälardalen Uni-
versity, Sweden. He has previ-
ously worked in the vehicle indus-
try as a Senior Software Engi-
neer at Arcticus Systems and as
a Embedded Software Consultant
for IKG Group, Sweden. His
research focus is on software
architecture and model-driven
development of complex, often
vehicular, software systems.
Within this context, he has co-
authored over 30 publications in
peer-reviewed international jour-
nals, conferences and workshops. He is a PC member and referee for
several international conferences and journals. He is a guest editor
of the Journal of Automotive Software Engineering. He has organ-
ised and chaired several special sessions and workshops at interna-
tional conferences such as ACM/IEEE Models and IEEE ICIT and
ITNG. For more information see http://www.es.mdh.se/staff/2662-
Alessio_Bucaioni.
Saad Mubeen is an Associate
Professor at Mälardalen Univer-
sity, Sweden. He has previously
worked in the vehicle industry as
a Senior Software Engineer at
Arcticus Systems and as a Con-
sultant for Volvo Construction
Equipment, Sweden. He is a Senior
Member of IEEE and a Co-chair
of the Subcommittee on In-vehicle
Embedded Systems within the
IEEE IES Technical Committee
on Factory Automation. His
research focus is on model- and
component-based development of
predictable embedded software, modeling and timing analysis of in-
vehicle communication, and end-to-end timing analysis of distributed
embedded systems. Within this context, he has co-authored over 125
publications in peer-reviewed international journals, conferences and
workshops. He has received several awards, including the IEEE Soft-
ware Best Paper Award in 2017. He is a PC member and referee
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1302 A. Bucaioni et al.
for several international conferences and journals respectively. He is
a guest editor of IEEE Transactions on Industrial Informatics (TII),
Elsevier’s Journal of Systems Architecture and Microprocessors and
Microsystems, ACM SIGBED Review, and Springer’s Computing
journal. He has organized and chaired several special sessions and
workshops at the international conferences such as IEEE’s IECON,
ICIT and ETFA. For more information see http://www.es.mdh.se/
staff/280-Saad_Mubeen.
Federico Ciccozzi is an Associate Pro-
fessor at Mälardalen University (Swe-
den). His research specializes in: def-
inition of DSMLs, model transforma-
tions, system properties preservation,
multi-paradigm modelling, model ver-
sioning, combination of MDE and
CBSE for complex systems, blended
modelling, language and compiler
engineering. Federico has organized
over 40 conferences, tracks, sessions,
workshops and journal special issues.
He has been program committee mem-
ber of 37 scientific events in the last
year. He is part of the editorial board
of IET Software, guest editor of SoSyM and JISA. He has (co-
)authored over 85 peer-reviewed publications. More info at: http://
www.es.mdh.se/staff/266-Federico_Ciccozzi.
Antonio Cicchetti is an Associate
Professor at the IDT department,
Mälardalen University, Sweden.
He got his Ph.D. in Computer
Science in 2008 at the Univer-
sity of L’Aquila with the thesis
entitled “Difference Representa-
tion and Conflict Management in
Model-Driven Engineering”. His
research interests include the
interplay of model-driven and
component-based engineering
techniques and their application in
the development of industrial sys-
tems. Moreover, he investigates
the general problems related to the design of modelling languages,
mutiview systems, and model transformations, in the context of
both academic research and industrial application. Further, he is
interested in the concerns related to the management of evolu-
tion of both language and models. He can be reached at anto-
nio.cicchetti@mdh.se. For more information see also http://www.es.
mdh.se/staff/198-Antonio_Cicchetti.
Mikael Sjödin is since 2006 a
professor of real-time system at
Mälardalen University, Sweden.
He is leading the research group
Model-Based Engineering of
Embedded Systems that focus on
development of methods and tools
for model-based engineering of
embedded systems. Including:
models for architectural and
behavioral descriptions of system
and requirements for systems, tech-
niques for analyzing and trans-
forming models, and runtime archi-
tectures for resource efficient,
predictable embedded systems. Since 2012 he is the research direc-
tor for Embedded Systems, a research environment with 200 active
researchers at Mälardalen University. Between 2000 and 2006 Mikael
held numerous industrial positions and worked as software architect
and project manager. Mikael received his Ph.D. and M.Sc. in computer
science from Uppsala University in 2000 and 1995 respectivly.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
1.
2.
3.
4.
5.
6.
Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers and authorised users (“Users”), for small-
scale personal, non-commercial use provided that all copyright, trade and service marks and other proprietary notices are maintained. By
accessing, sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of use (“Terms”). For these
purposes, Springer Nature considers academic use (by researchers and students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and conditions, a relevant site licence or a personal
subscription. These Terms will prevail over any conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription
(to the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of the Creative Commons license used will
apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may also use these personal data internally within
ResearchGate and Springer Nature and as agreed share it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not
otherwise disclose your personal data outside the ResearchGate or the Springer Nature group of companies unless we have your permission as
detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial use, it is important to note that Users may
not:
use such content for the purpose of providing other users with access on a regular or large scale basis or as a means to circumvent access
control;
use such content where to do so would be considered a criminal or statutory offence in any jurisdiction, or gives rise to civil liability, or is
otherwise unlawful;
falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association unless explicitly agreed to by Springer Nature in
writing;
use bots or other automated methods to access the content or redirect messages
override any security feature or exclusionary protocol; or
share the content in order to create substitute for Springer Nature products or services or a systematic database of Springer Nature journal
content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a product or service that creates revenue,
royalties, rent or income from our content or its inclusion as part of a paid for service or for other commercial gain. Springer Nature journal
content cannot be used for inter-library loans and librarians may not upload Springer Nature journal content on a large scale into their, or any
other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not obligated to publish any information or
content on this website and may remove it or features or functionality at our sole discretion, at any time with or without notice. Springer Nature
may revoke this licence to you at any time and remove access to any copies of the Springer Nature journal content which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or guarantees to Users, either express or implied
with respect to the Springer nature journal content and all parties disclaim and waive any implied warranties or warranties imposed by law,
including merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published by Springer Nature that may be licensed
from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a regular basis or in any other manner not
expressly permitted by these Terms, please contact Springer Nature at
onlineservice@springernature.com
... In case of ALs are already used, or the architect is familiar with existing ALs (e.g. EAST-ADL [56] or RCM [57] in the automotive domain), the concrete architecture can be modelled using any of these ALs. A technical bridge can be easily implemented by specifying model transformations, where the source metamodel is the existing AL and the target is ALmm. ...
Article
Full-text available
Reference architectures (RAs) are successfully used to represent families of concrete software architectures in several domains such as automotive, banking, and the Internet of Things. RAs inspire architects when designing concrete architectures, and they help to guarantee compliance with architectural decisions, regulatory requirements, as well as architectural qualities. Despite their importance, reference architectures still suffer from a number of open technical issues, including (i) the lack of a common interpretation, a precise notation for their representation and documentation, and (ii) the lack of conformance mechanisms for checking the compliance of concrete architectures to their related reference architecture, architectural decisions, regulatory requirements, etc. This paper addresses these two issues by introducing a model-driven approach that leverages (i) a domain-independent metamodel for the representation of reference architectures and (ii) the combination of model transformation and weaving techniques for the automatic conformance checking of concrete architectures. We evaluate the applicability, effectiveness, and generalizability of our approach using illustrative examples from the web browsers and automotive domains, including an assessment from an independent practitioner.
... Farrall et al. [233] and Copic et al. [178] also address supporting AUTOSAR; the latter looking at both Classic and Adaptive AUTOSAR. The evolution of the industrial component model for multi-criticality vehicular software is addressed by Bucaioni et al. [123]. In a wider context, Simo et al. [564] discuss the role of MCS within the context of Industry 4.0. ...
Book
This review covers research on the topic of mixed criticality systems that has been published since Vestal’s 2007 paper. It covers the period up to end of 2021. The review is organised into the following topics: introduction and motivation, models, single processor analysis (including job-based, hard and soft tasks, fixed priority and EDF scheduling, shared resources and static and synchronous scheduling), multiprocessor analysis, related topics, realistic models, formal treatments, systems issues, industrial practice and research beyond mixed-criticality. A list of PhDs awarded for research relating to mixed-criticality systems is also included.
... Regarding the combination of the identified integration mechanisms, the most frequent combination is Model Transformations and Links [51,65,31,66]. The combinations of Model Transformations and Metamodel Composition [67,68], Model Transformations and Co-Simulation [34,65], Links and Metamodel Composition [69] and Links and Co-Simulation [65] are also found. Finally, only one approach jointly uses the 3 mechanisms of Model Transformations, Links and Co-Simulation [65]. ...
Article
Full-text available
Cyber-Physical Systems (CPS) are heterogeneous and require cross-domain expertise to model. The complexity of these systems leads to questions about prevalent modeling approaches, their ability to integrate heterogeneous models, and their relevance to the application domains and stakeholders. The methodology for Multi-Paradigm Modeling (MPM) of CPS is not yet fully established and standardized, and researchers apply existing methods for modeling of complex systems and introducing their own. No systematic review has been previously performed to create an overview of the field on the methods used for MPM of CPS. In this paper, we present a systematic mapping study that determines the models, formalisms, and development processes used over the last decade. Additionally, to determine the knowledge necessary for developing CPS, our review studied the background of actors involved in modeling and authors of surveyed studies. The results of the survey show a tendency to reuse multiple existing formalisms and their associated paradigms, in addition to a tendency towards applying transformations between models. These findings suggest that MPM is becoming a more popular approach to model CPS, and highlight the importance of future integration of models, standardization of development process and education.
Article
Software product line engineering emerged as an effective approach for the development of families of software‐intensive systems in several industries. Although its use has been widely discussed and researched, there are still several open challenges for its industrial adoption and application. One of these is how to efficiently develop and reuse shared software artifacts, which have dependencies on the underlying electrical and hardware systems of products in a family. In this work, we report on our experience in tackling such a challenge in the railway industry and present a model‐based approach for the automatic generation of test scripts for product variants in software product lines. The proposed approach is the result of an effort leveraging the experiences and results from the technology transfer activities with our industrial partner Alstom SA in Sweden. We applied and evaluated the proposed approach on the Aventra software product line from Alstom SA. The evaluation showed that the proposed approach mitigates the development effort, development time, and consistency drawbacks associated with the traditional, manual creation of test scripts. We performed an online survey involving 37 engineers from Alstom SA for collecting feedback on the approach. The result of the survey further confirms the aforementioned benefits. We present a model‐based approach for the automatic generation of test scripts for product variants in software product lines. The approach is the result of the technology transfer between Mälardalen University and Alstom SA. We applied and evaluated the proposed approach on the Alstom Aventra software product line. In addition, we performed an online survey involving 37 engineers from Alstom SA. The evaluation showed that the approach mitigates the drawbacks of the traditional, manual creation of test scripts.
Chapter
Handling the software complexity of modern vehicular systems has become very challenging due to their non-centralized nature and real-time requirements that they impose. Among many software development paradigms for these systems, model-based development excels for several reasons including its ability to verify timing predictability of software architectures of these systems using pre-runtime timing analysis techniques. In this work, we propose a comprehensive framework that captures the timing related information needed for the modeling languages to facilitate these timing analyses. We validate the applicability of the framework by comparing two modeling languages and their respective tool-chains, Rubus-ICE and APP4MC, that are used for software development in the vehicle industry. Based on our results, both modeling languages support the design and analysis of vehicle software, but with different. Both modeling languages support time-, event- and data-driven activation of software components and modeling of single- and multi-rate transactions. Amalthea targets applications on single nodes with multi-core architectures while RCM focuses on single-core single-node and distributed embedded systems with ongoing work for supporting single-node multi-core architectures. In comparison to Amalthea, RCM provides a generic message model which can easily be re-modeled according to protocol-specific properties.
Chapter
In this paper, we propose a conceptual framework to facilitate the design and development of an automation system in which time-sensitive networking (TSN) is utilized for the backbone network and OPC UA is used for modeling of data exchange over TSN. As the configuration of OPC UA over TSN in a large automation setup can be a challenging task and requires specific expertise, we propose to add an abstract modeling layer that adopts the concepts of model-based development and component-based software engineering to facilitate the development of these systems. The proposed conceptual model can be automatically translated to the OPC UA modeling format. Such a modeling view will significantly reduce the complexity of OPC UA configurations, specially in large automation systems. Another benefit of the proposed framework is that the engineers, who do not have high levels of expertise in OPC UA, will be able to easily configure the OPC UA nodes in the automation system that utilize TSN for backbone communication.
Article
Emerging industrial digitization metaphors such as Cyber-physical Systems and Digital Twins increasingly advocate the use of distributed and autonomous modular solutions. This paper proposes a visual notation for modelling the timing properties of such modular industrial systems. The proposed work builds upon an existing notation that enables the analysis of the timing properties and requirements of potentially competing automation solutions. It provides a set of symbols that capture, among others: communication networks and devices, I/O interfaces and industrial controllers. The present work extends this preexisting notation by modelling the relation between physical devices and their controlling software in the context of industrial automation applications. The existing notation and its extensions are described and applied to a miniaturized automation system to illustrate its dual usage: as a tool to collect requirements and as a tool to analyse existing systems. The testing scenario highlights the opportunities provided by the extensions in comparison to the preexisting notation which, for the sake of completeness, is more briefly introduced and described.
Article
Full-text available
This paper introduces a novel model-driven methodology for the software development of real-time distributed vehicular embedded systems on single- and multi-core platforms. The proposed methodology discloses the opportunity of improving the cost-efficiency of the development process by providing automated support to identify viable design solutions with respect to selected non-functional requirements. To this end, it leverages the interplay of modelling languages for the vehicular domain whose integration is achieved by a suite of model transformations. An instantiation of the methodology is discussed for timing requirements, which are among the most critical ones for vehicular systems. To support the design of temporally correct systems, a cooperation between EAST-ADL and the Rubus Component Model is opportunely built-up by means of model transformations, enabling timing-aware design and model-based timing analysis of the system. The applicability of the methodology is demonstrated as proof of concepts on industrial use cases performed in cooperation with our industrial partners.
Conference Paper
Full-text available
The vehicular industry has exploited model-based engineering for design, analysis, and develop of single-core vehicular systems. Next generation of autonomous vehicles will require higher computational power, which can only be provided by multi-core platforms. Current model-based solutions and related modelling languages, originally conceived for single-core, can not effectively deal with multi-core specific challenges, such as core-interdependency and allocation of software to hardware. In this paper, we propose an extension to the Rubus Component Model, core of the Rubus model-based approach, for the modelling, analysis, and development of vehicular systems on multi-core. Our goal is to provide a lightweight transition of a model-based approach from single-core to multi-core, without disrupting the current technological assets in the vehicular domain
Article
Full-text available
The collective use of several models and tools at various abstraction levels and phases during the development of vehicular distributed embedded systems poses many challenges. Within this context, this paper targets the challenges that are concerned with the unambiguous refinement of timing requirements, constraints and other timing information among various abstraction levels. Such information is required by the end-to-end timing analysis engines to provide pre-run-time verification about the predictability of these systems. The paper proposes an approach to represent and refine such information among various abstraction levels. As a proof of concept, the approach provides a representation of the timing information at the higher levels using the models that are developed with EAST-ADL and Timing Augmented Description Language. The approach then refines the timing information for the lower abstraction levels. The approach exploits the Rubus Component Model at the lower level to represent the timing information that cannot be clearly specified at the higher levels, such as trigger paths in distributed chains. A vehicular-application case study is conducted to show the applicability of the proposed approach.
Article
Full-text available
According to the Model-Driven Engineering paradigm, one of the entry requirements when realising a seamless tool chain for the development of software is the definition of metamodels, to regulate the specification of models, and model transformations, for automating manipulations of models. In this context, we present a metamodel definition for the Rubus Component Model, an industrial solution used for the development of vehicular embedded systems. The metamodel includes the definition of structural elements as well as elements for describing timing information. In order to show how, using Model-Driven Engineering, the integration between different modelling levels can be automated, we present a model-to-model transformation between models conforming to EAST-ADL and models described by means of the Rubus Component Model. To validate our solution, we exploit a set of industrial automotive applications to show the applicability of both the Rubus Component Model metamodel and the model transformation.
Article
This survey covers research into mixed criticality systems that has been published since Vestal’s seminal paper in 2007, up until the end of 2016. The survey is organised along the lines of the major research areas within this topic. These include single processor analysis (including fixed priority and Earliest Deadline First (EDF) scheduling, shared resources, and static and synchronous scheduling), multiprocessor analysis, realistic models, and systems issues. The survey also explores the relationship between research into mixed criticality systems and other topics such as hard and soft time constraints, fault tolerant scheduling, hierarchical scheduling, cyber physical systems, probabilistic real-time systems, and industrial safety standards.