Keywords

1 Introduction

In the past decades, automotive software has been evolving at a staggering pace [22]. Advanced Driver Assistance Systems (ADAS) and other advanced features in contemporary and upcoming automotive software require high levels of computational power and high data-rate low-latency on-board communication that is well beyond the capacity of traditional single-core Electronic Control Units (ECUs) and on-board buses/networks respectively. One important consequence of this trend is that traditional distributed Electrical/Electronic (E/E) architectures are giving way to consolidated domain and centralised E/E architectures [1, 2]. The progression and evolution of the automotive E/E architectures is depicted in Fig. 95.1. While consolidated domain E/E architectures are realised by employing multi-core processors, centralised automotive E/E architectures are envisioned to leverage heterogeneous computing platforms, e.g., containing Central Processing Units (CPUs), Graphical Processing Units (GPUs) and Field Programmable Gate Arrays (FPGAs), which are connected by high-bandwidth and low-latency on-board backbone networks such as Time Sensitive Networking (TSN) [22].

Fig. 95.1
figure 1

Evolution of automotive E/E architectures and supporting model-based development methodologies

Full size image

The introduction of heterogeneous computing platforms has opened up several challenges including modelling of heterogeneous hardware architectures, modelling of software architecture, software to hardware allocation and ensuring quality, scheduling, timing and performance analysis of the software architectures, just to mention a few [8]. For instance, the support for modelling heterogeneous hardware architectures is a challenging task mainly because of the requirement of data and memory management in a predictable way as well as the requirement of satisfying real-time constraints at the design time [8]. The state-of-the-art model-based software development methodologies for automotive embedded systems are unable to address all these challenges, as depicted in Fig. 95.1. One crucial step for shifting the current model-based software development methodologies into the new of domain and centralised E/E architectures, is to provide modelling languages with support for describing the software architecture, the heterogeneous execution platforms and the software to hardware allocation. Note that many automotive software functions are time critical, i.e., they are required to provide logically correct responses at right times that conform to the specified timing constraints. Hence, the modelling for future automotive E/E architectures should be supported by timing analysis engines [10, 27, 29] and predictable run-time environments [3, 8, 24].

This paper draws on the industrial collaboration with the Swedish automotive industry for reporting on the advancement of model-based methodologies for the development of automotive software with respect to the evolution of automotive E/E architectures. In particular, this paper discusses on-going works with respect to architecture design (hardware and software co-design), support for timing analysis of the software architectures and provision of predictable run-time environment for distributed and domain E/E architectures. What is more, this paper describes a pragmatic vision on how to tackle the challenges of hardware and software co-design for centralised E/E architectures.

The rest of the paper is organised as follows. Section 95.2 describes a comparison between existing related approaches documented in the literature and our solution. Section 95.3 presents an industrial approach to support model-based software development on distributed automotive E/E architectures. Moreover, it discusses the partially available support for model-based software development on domain automotive E/E architectures. This section also discusses future plans for the software development on centralised automotive E/E architectures. Finally Sect. 95.4 concludes the paper and discusses the future work.

2 Related Work

In recent years, automotive software has been on the forefront of many software engineering advances including model-based development methodologies and real-time techniques [22]. This section presents the related research on modelling languages and approaches that are supported by end-to-end timing analysis and timing predictable run-time environments for distributed and domain automotive E/E architectures. Note that timing predictability is a well-known term in time-critical systems domain, where it is defined as a system-level property. A system is considered timing predictable under a set of assumptions if it is possible to demonstrate or prove at the design time that all timing requirements specified on the system are satisfied and that the system will certainly meet its timing when executed [17, 20, 25, 33, 34].

EAST-ADL is an architecture description language for the specification of automotive E/E architectures. It uses a multi-layer approach, where each layer describes the automotive architecture at a different abstraction level and from a different perspective [7]. At higher layers, EAST-ADL does not allow to explicitly model execution platforms being multi-core or heterogeneous. This means, that EAST-ADL supports modelling of software architectures for distributed automotive E/E architectures but for domain and centralised automotive E/E architectures. There are several works that allow timing analysis of software architectures that are modelled with EAST-ADL for distributed automotive E/E architectures [12, 13, 29]. However, there is no support for EAST-ADL to perform timing analysis to verify timing predictability of the software architectures on domain and centralised automotive E/E architectures. The EAST-ADL development methodology proposes to use domain-specific modelling languages (DSL) at the lower levels of abstraction, notably AUTOSAR [4], Rubus Component Model (RCM) [18, 24], and so forth. As a consequence, the work described in this paper can be considered as complementary to EAST-ADL.

AUTOSAR was created as an industrial initiative to provide a standardised software architecture at the implementation layer of the EAST-ADL methodology. AUTOSAR distinguishes among three software layers namely Application, Runtime Environment and Basic Software. In its last definition, AUTOSAR provides limited support for automotive software on multi-core platforms while it provides no-support for automotive software on heterogeneous platforms. This means that AUTOSAR supports modelling of software architectures and run-time environments for distributed and domain automotive E/E architectures but not for centralised automotive E/E architectures.

Based on AUTOSAR, APP4MC [5] is an open source platform for engineering embedded multi- and many-core software systems. This platform is mainly used within the automotive domain and relies on the AMALTHEA datamodels which provide support for modelling, e.g., hardware, software, mapping, stimuli, events, among others. AMALTHEA datamodels allow to describe both multi-core and heterogeneous platforms. Compared to the modelling approach leveraged in this paper, the AMALTHEA approach employs an extensive and explicit modelling of the execution platform (in terms of processing units, caches, memories, etc.) and of all the components of the automotive system including, e.g., operating system.

Similar to APP4MC, Distributed Real-time Architecture for Mixed criticality Systems (DREAMS) [6] is an European project which aims at developing a cross-domain architecture and design tools for networked complex systems supporting application subsystems with different criticality. DREAMS delivers metamodels implementing different views including, e.g., logical, physical and temporal.

Several works are based on the use of general-purpose languages such as UML as alternatives to automotive-specific languages. CHESS and GASPARD are examples of UML-based languages. The former allows to model complex component-based embedded systems in terms of their platform(s) and relevant properties, such as timing [15]. GASPARD is mostly used for the design of parallel embedded systems [16].

AADL [30] is an architecture description language conceived for the avionics domain, but it has been increasingly used for modelling embedded systems in general.

In crux, the state-of-the-art modelling approaches, timing analysis techniques and run-time environments provide a good, limited and no support for distributed, domain and centralised automotive E/E architectures respectively.

3 Model-Based Development of Automotive Software

In this section, we discuss the advancement of model-based methodologies for the development of automotive software with respect to the evolution of automotive E/E architectures shown in Fig. 95.1. In doing so, we draw on the industrial collaboration with Arcticus Systems,Footnote 1 a Swedish tool provider for international companies in the automotive industry such as Volvo Construction Equipment,Footnote 2 BAE Systems,Footnote 3 just to mention a few. During the last decades, the research collaboration between Arcticus Systems and Mälardalen University led to the definition of a model-based development methodology which is embodied in the Rubus Integrated Component model development Environment (Rubus-ICE). Rubus-ICE is based around the Rubus Component Model (RCM) which is a modelling language for distributed real-time embedded systems [14]. The methodology embodied in Rubus-ICE consists of four major phases: modelling, timing analysis, synthesis and deployment as shown in Fig. 95.1. As all the phases are carried out within Rubus-ICE, this methodology avoids explicit interoperability management and reduces time and cost overheads.

3.1 Model-Based Development of Automotive Software on Distributed Automotive E/E Architectures

Rubus-ICE provides a full-fledged model-based methodology for the development of automotive software on distributed E/E architectures. The development support includes modelling of the automotive software architectures and timing information (timing properties, requirements and constraints), end-to-end timing analysis of the software architectures, automatic generation of timing verified code from the software architectures, deployment and execution on predictable run-time environment. Figure 95.2 shows a screenshot of an example of a real-time system modelled and analysed on a distributed automotive E/E architecture.

Fig. 95.2
figure 2

Example of software development for real-time embedded systems on various Automotive E/E architectures using Rubus-ICE

Full size image

3.1.1 Modelling

Rubus-ICE fully supports modelling of software architectures on distributed automotive E/E architectures. Within Rubus-ICE, the automotive software architecture and its timing properties are modelled with RCM. In RCM, a Software Circuit (SWC) is the lowest-level hierarchical element and it represents the basic component that encapsulates one or more software functions. For example, the yellow boxes in Fig. 95.2, namely Logger, HMI and ACC represent three SWCs. Two or more SWCs may be encapsulated into a software assembly (ASM) for constructing the system at different hierarchical levels. An SWC has the run-to-completion semantics. In RCM, the interaction between SWCs is expressed in terms of data and control flow, separately. The SWCs communicate with each other via data ports. The component model facilitates analysis and reuse of components in different contexts by separating functional code from the infrastructure that implements the execution environment. RCM allows modelling of single-core processing units by means of node elements as shown by the model of two Node1 in Fig. 95.2. The nodes can be distributed, in which case they are connected by one or more models of networks. This is the case of the node elements Node1 and Node2 in Fig. 95.2 which are connected by the network element NW1. RCM supports modelling of various types of in-vehicle networks, including broadcast networks like Controller Area Network (CAN) [19] and its higher level protocols [28] and point-to-point networks like Ethernet Audio Video Bridging (AVB) [9] and TSN [26].

3.1.2 Timing Analysis

RCM allows expressing real-time requirements and properties on the software architecture of distributed automotive E/E architectures. To this end, the designer has to express real-time properties of SWCs, such as worst-case execution times (WCETs), stack usage, etc. The WCETs of the SWCs can be determined by using static WCET analysis tools such as SWEET [21]. The plugin framework in Rubus-ICE supports integration of such tools. The SWCs that are activated by periodic triggering sources, e.g., the Logger and ACC components in Fig. 95.2, are statically scheduled using the Rubus off-line scheduler. The scheduler constructs a schedule taking into account the specified real-time constraints. For event-triggered SWCs, response-time analysis [32] is performed and the calculated response times are compared with the specified timing requirements. The supported analysis, among others, includes distributed end-to-end response-time and delay analyses [27] and shared stack analysis [11].

3.1.3 Synthesis

While the software development using Rubus-ICE is independent of the underlying operating system (OS), code synthesizers are not. For this reason, Rubus-ICE accompanies the Rubus Real-Time OS (RTOS) designed for predictable execution of the software architecture. The Rubus RTOS supports both time- and event-triggered execution of tasks.Footnote 4 It optimises the run-time architecture by using the hybrid scheduling combining the static cyclic scheduling and the fixed-priority preemptive scheduling [23]. The Rubus RTOS has been ported to several different commercial-off-the-shelf processors [24].

3.1.4 Deployment

Within Rubus-ICE, the deployment phase involves both software and hardware platforms. The Rubus RTOS provides for the software platform. Although the software platform is OS dependent, it should be noted that the software architecture and corresponding synthesised code can be easily adapted and deployed to any RTOS. Similarly, any processing unit capable of running an RTOS, e.g., IBM’s PowerPC or ARM processor can serve as the hardware platform for deployment.

3.2 Model-Based Development of Automotive Software on Domain Automotive E/E Architectures

Domain E/E architectures employ more powerful multi- and many-core processing units for replacing the constellation of single-core units realising distributed E/E architectures. Currently, Rubus-ICE allows modelling of software architectures and specification of timing information of automotive software systems that are deployed on these architectures. For example, Fig. 95.2 shows an RCM model of a software architecture of a real-time system that is deployed on a tri-core node with multiple partitions per core (Node2). The support for timing analysis and predictable run-time support for real-time systems on these architectures is an ongoing work.

3.2.1 Modelling

RCM fully supports modelling of software architectures on domain automotive E/E architectures. In fact, in our previous work, we extended RCM for modelling automotive software on multi-core processing units [14]. The extension included the introduction of new modelling elements for describing multi-core processing units, software applications and their criticality levels, and the software to hardware allocation. Figure 95.3 shows the RCM extensions supporting multi-core platforms. Multi-core processing units are modelled in terms of node, core and partition elements. For instance, the node element Node2 in Fig. 95.2 is modelled as a tri-core processor comprising the core elements Core_0, Core_1 and Core_2. In turns, the core element Core_0 has two partition elements, namely Partition_1 and Partition_2. Within RCM, partition elements isolate parts of software from each others in both time and space. Isolation in time means that each partition gets a reserved share of the core processing time while isolation in space means that the memory available to each core is divided among its partitions. The extended RCM leverages an allocation mechanism which replaces the use of structural containment relations in favour of more flexible relationships among software and hardware elements. In particular, such relationships can only be specified among node, core, and partition elements and application, mode, assembly, and SWC elements.

Fig. 95.3
figure 3

RCM extensions supporting multi-core platforms

Full size image

3.2.2 Timing Analysis

Today Rubus-ICE uses offline scheduling to schedule software architectures on multi-core platforms. Moreover, resource partitioning techniques are considered for managing the shared resources such as cache memories and system bus. Hence, the scheduled software architecture is correct by construction from timing perspective.

3.2.3 Synthesis

Generation of code from the software architectures of the applications that are deployed on domain automotive E/E architectures is an ongoing work.

3.2.4 Deployment

The isolation in time and space is supported by the run-time layer, where the Rubus multi-core hypervisor uses resource-isolation techniques for arbitration of intra- and inter-core shared resources. As a result of using isolation techniques, each core and partition becomes (virtually) independent meaning that they can be seen as a single-core processor equivalent with dedicated system resources. One notable advantage of this is that the overall system becomes simpler to model as there is no need to explicitly model memories, I/Os and other shared resources in the software architecture.

3.3 Model-Based Development of Automotive Software on Centralised Automotive E/E Architectures

Centralised E/E architectures are envisioned to leverage heterogeneous hardware comprising of certified traditional processors and general-purpose high-performance processors with accelerators. As a result, centralised E/E architecture will require the integration of heterogeneous software with respect to, e.g., workloads, activation semantics, data-flow semantics, real-time requirements and safety requirements [31]. What is more, they open up to several development challenges including software architecture and quality, scheduling and hardware [8].

Currently, RCM supports the specification of heterogeneous software with respect to real-time properties and requirements, safety requirements and criticality levels (different Automotive Safety Integrity Levels (ASILs) A to D according to the ISO 26262 functional safety standard for road vehicles), activation semantics (time triggered, event triggered), data-flow semantics (synchronous, independent activation, task chains) and workloads. An on-going work is the extension of RCM with fine-grained modelling elements for the specification of heterogeneous hardware. This extension will include elements such as GPU, FPGA, memory, cache, etc. Support for timing analysis, synthesis and deployment are future works. To the best of our knowledge, there is no modelling framework or methodology that supports all the above mentioned development steps (shown in Fig. 95.2) for centralised automotive E/E architectures.

4 Conclusion and Future Work

This paper presents a component model, a development methodology and an integrated development environment that are used in the automotive industry. The tool chain, Rubus-ICE, supports model- and component-based development of embedded software FPR evolving automotive Electrical/Electronic (E/E) architectures. The paper also demonstrated how current industrial model-based methodologies support modelling, timing-analysis, synthesis and deployment of embedded software on distributed automotive E/E architectures. The paper also discussed on-going works for enriching industrial model-based methodologies with support for architecture design (hardware and software co-design), support for end-to-end timing analysis of the software architectures and provision of predictable run-time environment for embedded software on automotive domain and centralised E/E architectures. We identify that a full-fledged model-based software development methodology, development environment and run-time support for predictable automotive software on domain and centralised automotive E/E architectures is still missing. One line of future work encompasses provisioning of timing analysis, synthesis and deployment of embedded software on domain automotive E/E architectures. Another line of future work includes the definition of a reference architecture for heterogeneous platforms employed in the realisation of centralised automotive E/E architectures.