leveraging value of centralized computing solutions for ... · example the fusion actor could be...

Leveraging Value of Centralized Computing Solutions for Connected and Autonomous

Vehicles

The mobility industry is shaken by the advent of Artificial Intelligence and connectivity that paves the way for new applications and uses of mobile systems. The lack of agility and efficiency of the electrical and electronic infrastructure is, however, a road block to the adoption of these new technologies.

Cars Electrical and Electronic (EE) architectures are inherited from more than 35 years of incremental innovations where each feature addition leads to the integration of a new computer (ECU) in the car. The resulting architectures are known to be very reliable and they sustain a structured design process and supply chain that minimize production risks. With up to 100 ECU in high-end cars, these architectures however also create ever increasing integration concerns and fail to leverage the whole value of data produced by cars sensors.

In this old industry, Tesla has shown as early as 2013 that reconsidering EE architectures around a centralized computing solution allows to disconnect electronic concerns from car features development. This was the first step to revisit the user experience, leveraging on a flexible infrastructure enabling SW personalization and upgrades all along the vehicle lifecycle. Large suppliers are now also moving toward electronic aggregation in Domain Controller Units that gather multiple features inside specific multipurpose computers (e.g. for ADAS, cockpit or multimedia purpose). Some large car makers like the Renault-Nissan-Mitsubishi Alliance even see one step further with a single Vehicle Controller Unit to manage all the car features, mixing different types of software in single hardware. In this context, Mc Kinsey & Company in [1] highlights that centralized electronics in car will sustain a 7% CAGR to reach 43% of cars ECU at 2030 timescale.

Concentrating electronics in cars has obvious costs and integration benefits. But real electronics revolution comes from the decorrelation of electronic and

Leveraging Value of Centralized Computing Solutions for Connected and Autonomous Vehicles

- 2 –

feature lifecycles. Having a baseline electronic on top of which features can be developed and integrated in the car reduce time to market and increase marketing agilities, and also creates new opportunities in business relationships, reducing the entry ticket of innovative applications into cars. But opening centralized computing platforms comes with a couple of challenges amongst which:

– How to address cars electronics diversity and performance range from entry models to high end connected and autonomous cars?

– How to support the diversity of SW execution frameworks that will allow to capture the whole range of innovative applications, and at the same time minimize the car’s electronic entry ticket?

– How to safely manage the integration of multi-source features with the resource sharing, all along the SW lifecycle ?

Alkalee addresses these challenges starting from a very simple, yet formal, way to represent applications interactions, and leverages on this mathematical model in a system architecture and tools. We present the model’s foundations in the next section and describe the way we translate these foundations in a system modeling tool and embedded software. Next, we illustrate this approach considering a modular and heterogeneous computing solution, and discuss the solution benefits in managing adaptive braking system with Alaklee’s Toolsuite and platform.

Coordinated Efficiency as a Rule System modeling methods usually face the dilemma of 1) easing capture of asynchronous

communication to express interactions with physical world, or 2) formally describe sequences of operations to analyze temporal behavior of applications. Solutions favoring the modeling of interactions between distributed components usually rely on Data Flow modeling while time-triggered approaches are usually considered when timing analysis is of primary concern.

The modeling method must ease the advent of domain or vehicle computers in cars, that support the execution of multiples features, coming from multiple sources but run on the same hardware. In such conditions, we cannot afford to compromise any of the two elementary needs. Alkalee foundation is an innovative computation and communication model that combine best of the two worlds by allowing the modeling of timing information in asynchronous data flow model.

This formal model, whose properties have been demonstrated in [2] and [3], is made practical for complex models through the introduction of hierarchical modeling and dynamic reconfigurations. The formal model, called Polygraph, is depicted in the next section before presenting its application in tools and embedded platform.

Polygraph

A model in Polygraph, simply called a polygraph, represents the functions of a system (for example its Software Components) by actors. They communicate with each


- 3 –

other through unidirectional FIFO channels to receive input data to process, and send their results to other actors, who in turn process it as input data, and so on. An actor specifies how much data it expects per execution, and how much it produces. Actors wait until all their input data is available to start processing, so that the communications are determinate.

This typical data flow model is enriched with different kinds of annotations, each providing ways to accurately model the system’s behavior, without losing the capability to statically analyze essential behavioral properties. This model is entirely functional and provides a formal specification of the expected system behavior, regardless of implementation concerns. This way, any fundamental incoherence (one that no implementation can overcome) in the design can be detected and corrected before starting the specification of how the system will be implemented.

These annotations come under the form of frequencies to express real-time periodic behavior, and phases to express end-to-end latencies. These labels are not mandatory, so that some actors can compute as-soon-as data is available. In addition, to add flexibility to the design, any actor can associate mode labels to the data it produces, to differentiate many kinds of operational modes (polymorphic types for example). An actor reacts to mode labels on input data by choosing one of several predefined execution modes, effectively modifying its behavior for its next execution (activation or deactivation, variable execution time, type of produced data, …).

Figure 1 : A polygraph modeling a rear-view display, where each actor modeling a physical interface has a frequency; the display has a phase capturing the expected latency from the sensors, and it also sends mode labelled data to the sensor to deactivate some or all of the receiving actors.

Figure 1 illustrates the modeling of a simple rear-view display, relying on three sensors to draw camera images enhanced with obstacle highlights. It is important to note that we focus on the modeling of actor interactions. Content of the actor itself is not a concern in polygraph. It can indifferently be a polygraph to express hierarchy in the system (in the example the fusion actor could be refined by several computation stages), or a specific SW component satisfying any kind of programming model adequate for the execution target. This system-level approach allows us to manage the interaction between the SW components without constraining the development environment of those actors. Blackbox composition of the system is thus possible as soon as interfaces are exposed.

Euphilia

Polygraph enabled the development of a powerful Integrated Development Environment (IDE) providing tool support to the design and integration of


- 4 –

centralized computing platforms, called Euphilia. Euphilia leverages on the Papyrus Model Based System Engineering framework distributed by the Eclipse foundation ( [4] http://eclipse.org/papyrus). Our IDE proposes a unique vehicle software development framework compliant with the ISO 26262 standard part related to the product development at the software level. As illustrated in Figure 2 it helps SW integrators to verify software safety requirements starting from the software architectural design until the SW integration and testing through the implementation step.

Figure 2 : Euphilia viewpoints

Specification

The Euphilia entry point enables a modular modeling of the whole system. At this stage the user specifies functional interactions as well as timing constraints in compliance with Polygraph rules. As illustrated on

Figure 3, the Euphilia GUI allows drag and drop of basic Polygraph components and annotations (actors, channels, frequencies, etc.), so that users can focus on system level configuration of the platform. At any edition step, it is possible to check some properties of the specification, for example the absence of deadlocks and the correct synchronization of the communications (cf. [2], [3], and [4]). If this latter point fails, it means that the specification will eventually lead to undesirable effects like sample loss or out-of-sync samples on fusion kernel inputs. Simulation facilities are provided to the user to understand why the communications are not well-synchronized, and perform specification debug and tuning. This simulation interface also allows a system designer to check that his specification is not only correct, but corresponds to the behavior he had in mind.


- 5 –

Figure 3 : Main Euphilia ViewPoint.

Left side allows an easy project navigation and Right side provides the design palette to specify the application that is graphically represented in the middle of the view.

Configuration

Second Euphilia viewpoint exploits the formally verified model to size the platform and explore different hardware and software configurations. Euphilia has the ability to schedule and allocate all system activities leveraging on Polygraph theory. It allows to explore execution platform (Receef) configuration and demonstrate the schedulability of the system [5]. Results are displayed as gantt charts (WCRT) and pie charts (processor utilization) in a note book to ease platform efficiency analysis and optimize processor, memory or communication resources usage.

Platform configuration is finally exported to setup the Receef platform. It includes all that concern the application deployment on the virtual machines of the platform, including the generation of ARXML files to configure AutoSAR Adaptive Platform Machines (service-oriented interfaces, platform health-monitoring configuration, etc.).

Conformity

The conformity viewpoint in Euphilia allows to manage feature contracting, with internal development teams or external suppliers. It checks that developed features comply with the specification for all that concern temporal and communication interfaces. From the formally verified model, Euphilia generates an oracle, proved to represents all the expected communications generated by every agent of the system. This oracle is the foundation of the conformity process, as it allows to check if execution traces of suppliers’ features comply with their specified behavior.

The validation is based on symbolic execution techniques to find execution paths that must be covered by the runtime, to comply with the specification described in the formal system model. In case of deviation with respect to the model, some guided traces replay features in the simulation tools are available, to help understand what went wrong.

Receef

Receef is the embedded SW infrastructure that supports software component interactions (SWC) and manages time sensitive communications and safety concerns. As illustrated in Figure 4 it combines multiple Execution Partitions (EP) that may


- 6 –

run on multiple heterogeneous Computing SubSystems (CSS). For high-performance and general-purpose Computing Systems, Receef support the integration of hypervisors that enable multiple operating systems to run on a single CSS. Hypervisor and Execution Partitions selection depends on application needs, and the final decision is let to the customer that may use our benchmarking data for decision making [6].

Figure 4 : Receef SW platform components

Receef leverages the trend of Service-oriented Architectures (SoA) to enable communication at the system scale, regardless of the nature of the hosting CSS and OS. The many existing SoA middlewares hide the heterogeneity of the execution platform, and Receef currently supports the AutoSAR Adaptive Platform, with the ambition to quickly support other middlewares (e.g. ROS) to diversify the available Execution Platforms.

Beyond the use of novel approaches to software architecture, Receef benefits from the formal analyses conducted in Euphilia. Thanks to the information extracted during the configuration of the platform, the Receef Data Sharing Manager is in a position to detect any deviation with respect to the formal model, and is thus the cornerstone of Receef Real-Time and Safety Management. Invisible to the Software Components, it efficiently monitors timing and logical checkpoints along the end-to-end communication path. When possible it automatically configures or extends the standard available interfaces (e.g. AutoSAR End-2-End Protection and Platform Health Monitoring). When necessary, custom generated code handles the monitoring. Its features are not tied to a specific communication technology or middleware, so it can support for example communications over TSN, PCIe, or a legacy bus.

In case of abnormal communication, the DSM will manage error confinement and switch to degraded mode according user-configured recovery policies. One can notice that even if the primary focus of DSM is on real-time and safety management, the ability to monitor all system communications may be a strong asset when defining overall cybersecurity strategy.

Application to the FACE Platform FACE platform, jointly designed by CEA and Renault, embeds Alkalee’s technologies.

This Electrical and Electronic platform combine zonal approach for data aggregation and power distribution with centralized computation for decision


- 7 –

taking. As illustrated in Figure 5, Physical Interface Units manage data aggregation and power distribution in vehicle zones and interface legacy sensors and actuators with the computing system architecture around the Physical Computing Unit.

Figure 5 : FACE platform

Physical Computing Unit is a modular platform able to address the whole range of vehicle segments from the Renault-Nissan-Mitsubishi Alliance, through the addition of daughter boards. Entry configuration of the PCU leverage on a safety-oriented microcontroller RH850 and a general purpose Rcar-H3. Ethernet and PCIe switches enable the addition of daughter boards and DSM Core is implemented using a Xilinx Ultrascale component. In addition to Renesas RCarH3 and RH850, a portfolio including 3 types of daughterboard is available for PCU composition:

– RcarM3 daughter boards from Renesas allow to increase the general-purpose computing performances

– Bostan daughter boards from Kalray provide an extension for massively parallel processing like AI applications

– Xilinx Ultrascale daughter boards from CEA allows low latency processing solutions for example for fine grain data fusion [7]

Receef is available for any of the configuration depicted in Figure 6. The various Computing SubSystems support three types of Execution partitions, leveraging on ROS, RT Linux or Adaptive Autosar. The PikeOS hypervisor from Sysgo has also been implemented on the RcarH3 processor to support multiple Execution Partitions. FACE coordinates the system through the Polygraph Model of computation and communication and verify it at runtime through the Data Service Manager.

PCU

Rear LeftPIU

Rear RightPIU

Front RightPIU

TSN Ethnet BackbonePCU

Front LeftPIU

Fron

tPI

U


- 8 –

Figure 6 : Receef configurations supported in FACE project

Ability to manage a large product range has been demonstrated using an adaptive braking system, adapting vehicle speeds according to multiple information issued from several sensors and features developed by different teams and running in multiple execution environment and processors. Breaking decisions are taken according to short range obstacle detection with lidar, speed limit detection through neural network, or pedestrian detection with stereovision camera. The system-modeling of the application with Euphilia is displayed on

Figure 7.

Figure 7 : Configurable Adaptive Braking System.

It leverages on multiple data sources (odometer, Lidar, cameras) and vehicle perception functions to enslave vehicle speed to driving conditions. Euphilia exploit both functional and temporal information provided by the polygraph to enforce correct integration of the distributed functions.

The adaptive braking system specification takes benefits of polygraph features to model asynchronous and heterogeneous data streams and manage conditional execution of some of the features (e.g. pedestrian detection activated only at low speed). Li in [5] for example recorded a 78% performance improvement with respect to a fully


- 9 –

synchronous approach. Using this setup, the Receef platform is also in a position to detect temporal deviation coming from internal computing subsystem errors and to confine errors and jump into a secured degraded mode. Combination of Euphilia and Receef enables a smooth integration of features developed in third party environment.

From trend to revolution Centralization is a trend that impacts the whole automotive industry. It solves a couple of

concerns born from a long history of incremental innovations in Electrical and Electronic architectures. This step forward can however become a giant leap if we manage to open the EE box to the software application developers.

Through a system-level approach, Alkalee provides means to vehicle manufacturers and suppliers to leverage the value of centralized computers by managing feature integration during the whole vehicle lifecycle. We highlight through the FACE platform deployment example that we address the five key concerns during features integration:

– Safety & Real-Time are address all along the SW integration process through an innovative model of computation and ISO26262 tools

– Multi-sourcing management is enabled by the conformity checking that is shown to be of linear complexity according to the amount of feature providers

– Execution Framework diversity is highlighted with the FACE platform that supports 5 different CPUs and 3 Operating Systems

– HW Sizing is almost reduced by half thanks to the support of dynamic reconfiguration and asynchronous communications support.

– Products range can be very large thanks to the modular architecture support enabling the addition of multiple high end daughter boards increasing computation power from 40kDMIPS to 400kDMIPS.

Centralization benefits at the vehicle-scale, as demonstrated in the FACE program, has also direct applications to Domain Control Units. Especially Cockpit or ADAS domain are of primary concern for Alkalee as well as Defense and personal or goods transportation domains.


- 10 –

References [1] Mc Kinsey & company, «Automotive Software and Electronics in 2030,» july 2019.

[2] P. Dubrulle, C. Gaston, N. Kosmatov, A. Lapitre et S. Louise, «A Data Flow Model with Frequency Arithmetic», International Conference on Fundamental Approaches to Software Engineering (FASE), 2019.

[3] P. Dubrulle, C. Gaston, N. Kosmatov et A. Lapitre, «Dynamic Reconfigurations in FrequencyConstrained Data Flow», International Conference on integrated Formal Methods (IFM), 2019.

[4] «Papyrus,» [En ligne]. Available: https://www.eclipse.org/papyrus/.

[5] D. Irofti et P. Dubrulle, «Local Consistency Check in Synchronous Data Flow», Formal Methods - The next 30 years, 2019.

[6] S. Li, P. Dubrulle, S. Louise et C. Mraidha, «Schedulabilty Analysis of real-time conditional data flow applications», International Workshop on Timing Performance engineering for Safety critical systems (TIPS), 2018.

[7] E. Hamelin, M. Ait Hmid, A. Naji et Y. Mouafo-Tchnida, «Selection and evaluation of an embedded hypervisor : application to an automotive platform», European congress on Eembedded Real-Time Systems (ERTS), 2020.

[8] E. Piriou, C. Flouzat, B. Jovanovic et M. Oussayran, «An automotive video acquisition and processing platform», Design Automation and test in Europe (DATE), 2020.

[9] S. Li, M. Morelli, A. Redermacher, J. Tatibouët, P. Deville, A. Lapitre, S. Gerard et C. Mraidha, «Polygraph Tool Suite: Configuration and Conformity Validation for DataFlowBasedReal-TimeSystems», chez Real-Time Systems Symposium (RTSS), 2019.

leveraging value of centralized computing solutions for ... · example the fusion actor could be...

Documents