Modelling multi-criticality vehicular software systems: evolution of an industrial component model

The purpose of RCM is to express the infrastructure for software functions. In RCM, a software circuit (SWC) is the lowest-level hierarchical element and its purpose is to encapsulate 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 important 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 principle 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 follows: An example software architecture of a single-node system modelled with RCM, depicted in Fig. 1, shows how components interact with external events and actuators with respect to both data and triggering. The figure also shows the internal 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).

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 calculations are performed and compared to the corresponding timing requirements. The analysis engines support various types of timing analysis that include response-time analysis and end-to-end data propagation delay analysis [20].

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 allocated 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 memory to each individual task. This optimisation results in a small runtime footprint of the software architecture.

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 Application 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]. Similarly, 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 partitions within those cores, to become virtually independent from other cores and their partitions. In other words, each partition 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 overall 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.

Numerous research efforts,⁵ AMALTHEA/APP4MC,⁶ 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 standards. 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 complexity of eliciting and specifying all the details such that the tooling support would work as expected (e.g. validation 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 language and surrounding tooling, relieving the users from the burden of specifying all the details. However, major technical 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).

There exists a number of languages that support modelling of timing properties and requirements in vehicular embedded 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 Description Language (TADL) [33] and inspired by MARTE [34]. TADL is redefined and released in the TADL2 [35] specification 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 linking 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 systems. Most of the above cited languages such as AUTOSAR, 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 modelling 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.

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 definitions 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 complete application and not to individual software components or tasks within the application. This latter model complies with various standards such as the functional safety standard 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, development 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 prohibitively 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 scheduling 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 particular, 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 environment, 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 allocation 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 solutions 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 systems. Notably, in [42] the authors illustrate the safety argumentation for an automotive case study based on the AURIX processor family. Those concerns however fall outside of the scope of this paper, since its primary goal is to spare the need to re-certify the Rubus kernel.

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 scheduling 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 development [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 different 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, software 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 considered as complementary to EAST-ADL. Indeed, we have already shown in [51, 52] how to employ model transformations to close the abstraction gaps between EAST-ADL and 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 increasingly 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 transformations generate opportune extensions of the input models to enable the analyses mentioned earlier. The UML profile 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 simulation. In particular, the software components modelled in UML are complemented with hardware and software to hardware allocation specifications by means of MARTE. Instead, in [55] the authors propose to employ MARTE for system development of component-based systems: MARTE models describing the system are completed with allocation of components information through automated code generation. 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 supports code generation for formal verification, simulation and hardware synthesis. On a similar line of research, the COMPLEX 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 optimisation of the designed system architectures, e.g. to maximise parallel execution, while in general safety/certification issues are not taken into account.

In order to provide such a flexibility while ensuring backward compatibility with legacy RubusMM models, we have modified the existing hierarchy as follows. We have added the metaclasses TargetLegacy and TargetNew, both inheriting from the abstract metaclass Target. TargetLegacy represents a legacy (single-core) processor and it contains one or more Mode elements. This containment is specified through the reference mode. TargetNew represents a single- or multi-core processor and contains one or more Core elements, which in turn can contain Partition elements. TargetNew, Core and Partition elements inherit from the abstract metaclass 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.

The metaclass Target 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 target processor in a host environment such as Windows or Linux. Both TargetLegacy and TargetNew inherit the speed and type attributes. Moreover, TargetNew provides additional multi-core specific attributes. numberOfCores specifies the number of cores composing the TargetNew, and it is used by the model-based timing analysis and to automatically allocate software to hardware. The reference core links Core elements to their respective TargetNew elements.

Core may contain Partition elements. The attribute numberOfPartitions specifies the number of partitions within a Core and the reference partition links them to the Core elements. 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 Partition 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 mechanisms. As discussed above, the isolation in time and space is supported by the Rubus multi-core hypervisor by means of resource-isolation techniques [21].

Target, TargetLegacy, TargetNew, Core, Partition, Allocator, Allocatable, as well as their attributes and related references were not part of the previous RubusMM definition [52]. It is important to note that the modelling elements describing multi-core processors could have been introduced without modifying the original structural containment. 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.

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 automotive 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)⁹ as an invariant of Partition elements. Listing 1 shows the pseudo-code for such a constraint.

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.

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 containsPortData and PortTrig elements. The PortData elements manage the data communication among SWC deployed on the same Target. The PortTrig elements manage the activation of the SWC elements. A PortNetwork is a port for the data communication of SWC elements deployed on different Target elements. The PortData elements of a Core are referenced to the PortData elements of the SWCs allocated on that Core. Similarly, the PortNetwork elements of a Node are referenced to the PortNetwork elements at SWC level. An Assembly groups SWC and Assembly elements in a hierarchical 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 Allocatable. A Mode groups Assembly and SWC elements and it is used for modelling a specific configuration of the software 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 allocation of software to hardware. More precisely, an Allocatable element can be deployed to an Allocator element by setting the isAllocated reference. Application, Allocatable, Allocator, and related references were not part of the previous RubusMM definition.