The complexity of vehicular embedded systems is continuously increasing and this can negatively a ect their development cost and time to market. One way to alleviate these issues is to anticipate analysis of system properties at design time for early architectural renements. In this paper, we present a licentiate work which aims at contributing to this e ort. In particular, considering the importance of timing constraints typical of vehicular embedded systems, we leverage Model-Driven Engineering for realizing an automatic approach which allows the developer to perform timing analysis on design models, without having to manually specify timing elements. The proposed approach, starting from a high-level model of the vehicular embedded application, generates a set of candidate models enriched with timing elements in a semi-automatic manner. Timing analysis is run on the generated models and, based on its results, the approach supports the selection of the best candidate model for a speci c, non-empty, set of timing constraints.
During the last decades, ever-growing complexity of vehicular embedded systems development negatively a ected their development cost and time-to-market [17]. To mitigate these issues, a common practice is to anticipate analysis of systems properties at design time to drive early architectural re nements. In this paper, we present a licentiate work3 which aims at contributing to this e ort. More precisely, we propose an approach to allow the developer to perform end-to-end and delay timing analysis4 5 on design models without having to manually specify their timing elements. Starting from a high-level model of a vehicular embedded application, we provide a semi-automated mechanism for generating a set of ? Copyright held by the author. 3 Within the Swedish Higher Education Systems, the Degree of Licentiate is a thirdcycle quali cation formally equivalent to half of the Degree of Doctor. 4 In the remainder of the paper we will refer to end-to-end and delay timing analysis simply as timing analysis. 5 We refer the reader to [13] [18] for further details on timing analysis. candidate models enriched with timing elements with the aim of enabling early timing analysis. Leveraging the timing analysis results, we support the selection of the best candidate model for a speci c, non-empty, set of timing constraints.
One of the rst attempts in mitigating the increasing complexity of vehicular
embedded systems development was the establishment of di erent views [14],
each of which often exploiting a speci c language, in the software development.
As a result, the vehicular software development was characterized by a plethora
of heterogeneous languages each targeting speci c aspects related to a
particular view. Nevertheless, the usage of heterogeneous languages introduced new
challenges towards interoperability, e.g., integration between general purpose
languages, e.g., UML, and domain-speci c languages, e.g., AUTOSAR. In
trying to solve to these challenges, the vehicular embedded research community
developed a layered architectural language, namely EAST-ADL [
EAST-ADL proposes a top-down development process composed by four different abstraction levels, i.e., vehicle, analysis, design and implementation level. Within EAST-ADL, interoperability is ensured by well-de ned relationships among elements in the di erent abstraction levels. Nevertheless, these relationships are not leveraged in any mechanism supporting the automatic translation of di erent artifacts through the EAST-ADL abstraction levels. For this reason, automotive industry is currently pushing for having a closer linkage among the EAST-ADL abstraction levels for enabling a seamless development chain that takes into account relationships among di erent levels. Such a chain would improve the development of vehicular embedded software by providing automation of tedious and error-prone activities, e.g., transition from one level to another. Towards this goal, the vehicular embedded research community is considering the adoption of Model-Driven Engineering (MDE).
EAST-ADL. EAST-ADL [
Vehicle Level.The highest abstraction level is represented by the vehicle level, which captures information regarding the system's functionality. Feature models can be used for showing what the system provides in terms of functionality. These models are decorated with requirements. The vehicle level is also known as end-to-end level as it serves to capture requirements and features on the endto-end vehicle functionality. Analysis level. At the analysis level, vehicle functions are expressed, using formal notations, in terms of behaviors and interfaces. Yet, design and implementation details are omitted. At this stage, high level analysis for functional veri cation can be performed.
Design level. At this abstraction level, the analysis-level artifacts are re ned with design-oriented details: while the analysis level does not di erentiate among software, middleware and hardware, the design level explicitly separates them. Allocation of software functions to hardware nodes is expressed at this level too. Implementation level. At the implementation level, artifacts introduced at the design level are re ned with implementation details. At this stage component models, e.g., RCM, AUTOSAR, can be used to model the system in terms of components and interactions among them. The output of this level is a complete software architecture which can be used for code generation.
Rubus Component Model Rubus Component Model (RCM) is a component model for the development of resource-constrained embedded real-time systems. It is developed by Arcticus Systems AB in collaboration with Malardalen University and it is currently adopted by several companies as alternative to, e.g., AUTOSAR. In fact, in contrast with its competitors, RCM o ers high-precision timing analysis together with a well-established supporting framework.
In the context of EAST-ADL abstraction levels, RCM is used at the implementation level (Figure 1). Its main goal is to express the software architecture in terms of software functions and interactions among them. In RCM, the basic entity is the so-called software circuit (SWC) which represents the lowest-level hierarchical element in RCM and it encapsulates basic software functions. Each SWC is de ned by its behavior and interface. Interfaces manage the interactions among SWCs via ports. RCM distinguishes between data and control ow. Therefore, the interfaces have two types of ports: data ports for the data ow and trigger ports for the control ow. SWCs are characterized by run-to-completion semantics meaning that a SWC, upon triggering, reads data from the data input ports, executes its behavior and writes data on the data output ports. SWCs can be grouped and organized in assemblies, for decomposing the system in a hierarchical manner. Modes are used to distinguish among di erent states of the system. That is, each mode describes the architecture of the functions which are relevant for that mode. Target entities are used for grouping modes that are deployed on the same Electronic Control Unit (ECU). Moreover, they provide details regarding hardware and operating system. Node is a hardware and operating-system independent abstraction of a target entity. Finally, System is the top-level hierarchical entity, which describes software architecture for the complete vehicular system. RCM facilitates analysis and reuse of components in di erent contexts by separating functional code from the infrastructure that implements the execution environment.
The RCM metamodel de nition is part of the intended research contributions of the Licentiate thesis.
The rest of the paper is organized as follows. Section 2 describes the research problem. Section 3 presents the proposes solution and the related research contributions. Section 4 describes the work-to date and the current status. Finally, Section 5 and Section 6 discuss the validation methodologies and related work, respectively.
In this section, we discuss the research goal for the licentiate work, together with the research challenges to be tackled towards its achievement.
Given the timing constraints typical of vehicular embedded applications, anticipating timing analysis is a way for mitigating development issues, such as cost and time-to-market. Within the EAST-ADL development methodology, the way towards early timing analysis is hampered by the weak linkage between the modeling language used at the implementation level - where timing analysis is usually performed - and the design level. The goal of this licentiate research work is to provide a semi-automated support for allowing timing analysis on design models, without the need of manually adding their timing elements.
RC 1 { De nition of a metamodeling characterization of RCM. Although EAST-ADL does not fully embrace the MDE paradigm, the languages de ned for the abstraction levels are formalized by metamodeling. For this reason we want to leverage MDE for automating the development of the vehicle embedded software in EAST-ADL. To this end, all the involved languages have to be provided with a proper metamodel de nition. In our case, the challenge is the de nition of a metamodel for RCM, the language used at implementation level.
RC 2 { De nition of a mapping between EAST-ADL design level metamodel and RCM metamodel. Due to the lack of timing information, high-precision timing analysis can not be performed at the EAST-ADL design level. One way to solve this issue, is the automatic translation of design level models to implementation level models, i.e., RCM models, on which timing analysis can be performed. RCM models contain in fact timing elements, e.g. clocks, control- ow ports, to mention a few, that cannot be modeled at the design level. These elements represent a variability points in the transition from design to implementation level, meaning that more than one RCM model can be a valid translation of a given EAST-ADL design level model. The challenge is to de ne and implement a semi-automatic translation such that all the possible RCM models for a given EAST-ADL design level model are produced without any error-prone and time consuming manual activity. Semi-automatic in the sense that, while timing elements (e.g., clock, control ow port) can be fully automatically speci ed, their completion with actual timing properties (e.g., clock period, wcet) is still guided by the developer.
RC 3 { De nition of a mechanism for the selection of the best RCM model for a set of timing constraints. Starting from the generated RCM models, the challenge is to de ne a mechanism able to, based on the analysis results, select the RCM model which better meets the given set of timing constraints. In fact, at the end of the process, starting from a design level model, either an RCM model is chosen or re nements of the design level model are needed. This represents the last step for exploiting timing analysis results at design level for early enabling software architecture re nements. 3
The contribution of the licentiate work presented in this paper, is the de nition of a process which, from a design level model, generates a set of candidate implementation level models enriched with timing elements whose properties are set at generation time by the developer. That is to say, the developer drives the automatic generation of all the relevant combinations of timing elements by inserting timing properties only once per element instead of having to manually edit all the generated models. At this point timing analysis can be run and from its results, the best candidate implementation model, for a speci c timing property or a set of them, is selected. Figure 2 depicts the proposed approach and it also provides a breakdown of the overall contribution in speci c research contributions (RCOs).
RCO 1 { RCM metamodel. This contribution, marked as 1 in Figure 2, provides a metamodel de nition for RCM. The metamodel has been realized as an Ecore model, within the Eclipse Modeling Framework 6 (EMF). The de nition of the metamodel comprised the addition of some modeling elements, e.g., connectors, as well as the re nements of already existing elements relations, e.g., ports and data element hierarchies.
RCO 2 { DL2RCM transformation. This contribution, marked with 2 in Figure 2, provides a model to model transformation between EAST-ADL design level metamodel and RCM metamodel (DL2RCM). The transformation has been implemented by means of a bidirectional model transformation language, namely Janus Transformation Language (JTL). To the best of our knowledge, JTL is
the only transformation language able to deal with non-bijective transformations by possibly producing multiple results. The contribution of the DL2RCM transformation is two-fold. On the one hand, it allows the automatic translation of EAST-ADL design level models to RCM models. On the other hand, it does not impose restrictions on the generation of the RCM models, i.e., it is able to generate all the possible RCM models for a given EAST-ADL design level model. For instance, given the EAST-ADL design level model depicted in Figure 3a and considering the generation of clocks in the RCM models, the DL2RCM transformation will produce the RCM models depicted in Figure 3b. (a)
(b)
Sensor Controller Actuator software component software component software component (a) EAST-ADL Design level model of a component chain 10 ms
Sensor Sensor Controller Actuator Input SWC SWC SWC
(a) Software Circuit (SWC) 10 ms
10 ms 10 ms
Sensor Sensor Controller Input SWC SWC
(b) 10 ms 10 ms
Actuator SWC
Trigger sink
Data sink Trigger port
Trigger sink Data sink Data port
Trigger sink
Data sink Sensor Sensor Input SWC
Controller
SWC (c)
Actuator
SWC (b) Possible RCM models of the EASTADL design level model of the component chain in Figure 3a RCO 3 { Mechanism for the best RCM candidate selection. This contribution, marked as 3 in Figure 2, provides a conceptual mechanism supporting the selection of the best RCM model for a speci c, non-empty, set of timing constraints as the last step in the process of anticipating timing analysis at design level for enabling early architecture re nements. For each generated RCM model, timing analysis is applied. Analysis results together with a non-empty set of timing constraints, are the inputs of the mechanism that checks analysis results versus timing constraints to identify, possibly the best RCM candidate implementation model. If the mechanism fails in identifying a candidate, early architecture re nements at the EAST-ADL design level model may be needed.
In [7], we present the metamodel de nition for RCM which focuses on the de nition of metamodeling elements representing the software architecture. A work describing an extension of the RCM metamodel including the de nition of new structural elements and elements used for describing timing information is currently under review at the Journal of Systems and Software7. In the same work, we also demonstrate the applicability of the RCM metamodel by conducting an automotive application case study. In [8] we propose a two-phase methodology which supports the extraction of timing models from EAST-ADL designlevel models with the aim of anticipate timing analysis at design level. Within the proposed methodology, the software architecture at design level is automatically transformed to all the meaningful implementation-level models. The end-to-end timing analysis is performed on each generated implementation-level model and the analysis results are fed back to the design-level model. The aforesaid methodology is based on a model-to-model transformation between models conforming to the EAST-ADL design-level metamodel and models conforming to RCM metamodel (DL2RCM). The DL2RCM transformation has been implemented within the Eclipse Modeling Framework8 using JTL [9]. The proposed methodology is concretely integrated in an industrial tool used by automotive companies. We are planning to validate the methodology by means of an industrial case study and submit the results of this validation to the International Conference on Model Driven Engineering Languages and Systems9.
The works presented in [7], has been evaluated upon an industrial case-study. In
[7], we demonstrate the applicability of the RCM metamodel by de ning a
modelto-model transformation between models conforming to the RCM metamodel
and models conforming to AUTOSAR [
This section discusses some literature related to our problem and contributions.
In this section we discuss modeling languages and methodologies speci cally tailored for the development of vehicular embedded systems.
AUTOSAR. AUTOSAR [
AUTOSAR metamodel describes the software development at a higher level of abstraction compared to RCM metamodel. Unlike RCM, it does not separate control and data ows among software components nor di erentiate between the modeling of intra- and inter-node communication. Despite these di erences, there are some similarities between AUTOSAR and RCM, e.g., the sender receiver communication mechanism in AUTOSAR is very similar to the pipe-andlter communication mechanism in RCM. AUTOSAR is more focused on the functional and structural abstractions, hiding the implementation details about execution and communication. Whereas, RCM supports the modeling, analysis and synthesis of the execution environment of software functions. Essentially, AUTOSAR hides the details that RCM highlights.
TIMMO/TIMMO-2-USE. TIMMO [5], a large EU research project, is an initiative to provide AUTOSAR with a timing model. To this end, it provides a predictable methodology and language, called TADL [3] for expressing timing requirements and constraints. TADL is inspired by MARTE [6] which is the UML pro le for the model-driven development of real-time and embedded systems. TIMMO methodology makes use of the EAST-ADL and AUTOSAR interplay. Although the TIMMO project has been evaluated upon prototypes, to the best of our knowledge, there is no concrete industrial implementation of it.
TIMMO-2-USE [4], a follow up project, presents a major rede nition of TADL and new functionality for supporting the AUTOSAR extensions regarding timing model. Although both TIMMO and TIMMO-2-USE attempt to annotate AUTOSAR with a timing model, this may be hard to accomplish as AUTOSAR aims at hiding implementation details of execution environment and communication using the VFB.
TIMMO-2-USE proposes a methodology for the software development of vehicular embedded systems solving particular issues related to the timing modeling. The methodology is based on the EAST-ADL abstraction levels and it introduces, for each level, a set of activities to perform in order to ensure the software timing requirements. Compared to the proposed solution, the TIMMO2-USE methodology does not provide of automation nor supports early timing analysis.
In the last decades, several works investigated how to automatize the interplay between EAST-ADL and AUTOSAR through MDE. In this respect, in [19], the authors investigate the relationship between concepts of EAST-ADL and AUTOSAR. The authors use three case studies as drivers for the empirical establishment of these relationships. Nevertheless, the work only considers behavioral aspects and timing constraints from the control systems development view. Thus, it might be considered as a rst step towards the automatic synthesis of an AUTOSAR architecture from EAST-ADL.
Similarly, in [10] the authors present a mapping between EAST-ADL and AUTOSAR artifacts. Nevertheless the mapping is limited only on few EASTADL elements and events. Furthermore, as EAST-ADL evolved, the mapping is no longer valid.
The work in [15] aims at achieving model synchronization between SysML and AUTOSAR using Triple Graph Grammars (TGG) [16]. The proposed approach is developed in an industrial project. The work represents one of the rst attempts in using MDE for achieving model synchronization within the vehicular embedded domain. Nevertheless, compared to EAST-ADL, the adopted SysML pro le is very generic and it does not cover most of the vehicular aspects of the software systems. On the other hand, having a more tailored language, such as EAST-ADL, would make the synchronization hard to achieve due to the underneath non-injective relations [12].
Although the work presented in this paper does not address design space exploration, the generation of candidate models and their evaluation are two of the four common steps for design space exploration. The work in [20] describes a MDE approach which allows the automatic selection of the most adequate modeling solution for application, platform, and mapping between application and platform. The approach is based on an iterative algorithm which evaluates a candidate model per iteration, until the optimum is found. With respect our solution, such an approach does not generate all the candidate models in a single execution; rather, by means of heuristics, it considers a model per iteration. Similarly to the work proposed in this paper, in [11], the authors exploit JTL, for an automatic deployment exploration technique based on re nement transformations and platform-based design. More precisely, JTL is used for realizing the so-called re nement transformations responsible for the design space exploration. Di erently from our approach, the re nements transformations are endogenous, i.e., the involved source and target metamodels are the same, as the source and target models both conform to the AUTOSAR metamodel.