Reuse Strategy at Siemens VDO Automotive : The EMS 2 Powertrain Platform Architecture

International audienceA modern engine management system has to cope with a big amount of conflicting requirements, and should inparallel be sufficiently flexible to address the increasing wish of car manufacturers to differentiate from competitors.In order to fulfill these requirements, new solutions have to be introduced, which are open enough to makeallowance for future technology trends. A promising approach is the introduction of a modular architecture as anecessary means for the definition of a scalable and adaptable platform. Siemens VDO Automotive addressed thischallenge with the introduction of the EMS 2 platform, and showed that standardization need not to be incontradiction with flexibility. Right from the early definition phase, specific focus was given to the car manufacturers'needs, i.e. to allow the integration of competitive customer owned functionalities and technologies. The development of concepts for modular architectures has been carried out in different domains and is largely documented. A constant challenge is the definition of efficient processes and the necessary adaptation of the organization, in order to take advantage of the dedicated platform. This applies to the introduction of a new platform within an existing organization, as well as for its maintenance. With the EMS 2 platform architecture Siemens VDO Automotive is prepared to support different types of business models, while taking full advantage of a platform's features

Deterministic Execution Sequence in Component Based Multi-Contributor Powertrain Control Systems

International audienceModern complex control applications, e.g. engine management systems, typically are built using a component based architecture, enabling the reuse of components and allowing to manage the complexity of the application in terms of functional content, size and interfaces. This approach of independently developed components is supported by the concepts available in AUTOSAR and therefore can be expected to gain increasing importance. However, due to the nature of the task of control applications there still is a strong coupling between individual parts of the components resulting in signal chains and consequently in sequencing requirements. The challenge to get such execution sequences implemented correctly is increased, as often the components are delivered by different and external parties. Our approach extends the idea of functional partitioning of the application into the time domain by defining a system of phases with a fixed sequence and a defined content. This allows to design components right from the beginning into this sequencing frame like they are designed today into the component partitioning frame and to define a system sequencing across different suppliers

From Relevant High-level Properties to WCET Computation Improvement

The scheduling of real-time systems requires knowing the Worst Case Execution Time (WCET) of their tasks. WCET analysers compute timings by analysis of the low level behaviour of the target task. This document presents improvements in the WCET computation allowed by taking into account high level behaviours of the tasks. We first classify high level knowledge according to the relevance with respect to WCET estimation. We then propose a systematic method to bring this information back to the low level on which operate most WCET analysers. This approach separates the concerns of stating properties, integrating properties and computing a WCET aware of these properties

When the worst-case execution time estimation gains from the application semantics

International audienceCritical embedded systems are generally composed of repetitive tasks that must meet drastic timing constraints, such as termination deadlines. Providing an upper bound of the worst-case execution time (WCET) of such tasks at design time is thus necessary to prove the correctness of the system. Static timing analysis methods compute safe WCET upper bounds, but at the cost of a potentially large over-approximation. Over-approximation may come from the fact that WCET analysis may consider as potential worst-cases some executions that are actually infeasible, because of the semantics of the program and/or because they correspond to unrealistic inputs. In this paper, we introduce a complete semantic-aware WCET estimation workflow. We introduce some program analysis to find infeasible paths: they can be performed at design, C or binary level, and may take into account information provided by the user. We design an annotation-aware compilation process that enables to trace the infeasible path properties through the program transformations performed by the compilers. Finally, we adapt the WCET estimation tool to take into account the kind of annotations produced by the workflow

A Multi-Core Basic Software as Key Enabler of Application Software Distribution

International audienceIn the last 20 years, functional evolution in the automotive Powertrain has been motivated by three main pillars: low CO2 emissions (synonym to low fuel consumption), low emissions (particles, NOx, Co, HC), increase of torque throughput.In addition to these permanent objectives (e.g. Euro 4 ... Euro7 standard), new constraints are rising up now, like integrated transmission systems, electrification, autonomous driving, connectivity, etc...Finally, new complexities have to be handled, and high-end system is not anymore synonym of high cylinder number. Such system requires today 6 times as much computation power as 15 years ago, when 32 bits controllers (MPC 563 @ 40MHz) were introduced. Similarly, we estimate the needed computation power in 2022 to be twice compared to today.Such need cannot be reached anymore by increasing frequency (from 40Mhz in 2003 to 300MHz today) and reducing silicon structures (from 130 to 40 nm), but only by multicore computing.Nevertheless, multicore architecture does not provide automatically a gain of performance, particularly for highly coupled systems with high connexion with the HW, and hard real-time requirements. It might even be counter-productive, if not properly handled.The challenge of sharing memory cross cores in an efficient way has already been presented in a previous ERTS2 edition. We want now to elaborate on the importance of a well prepared basic software.A classical embedded SW (as defined by AR, too) is split in parts:The high level applicative SW (ASW) must be architectured in a way, that it can be easily reused cross platforms, and project configurations (4, 6 cylinders, gasoline, diesel, ...).Its reusability cross different HW platforms is ensured by the basic software (BSW), that gives access to the peripherals abstracting different HW controllers & ASIC families (different suppliers, from 1 to 6 cores, ...).In this contribution, we will elaborate on the main BSW principles that allowed us to efficiently use the performances of the new multicore controller. In addition to efficiency, a maximum freedom in the allocation of the ASW Runnables is required, knowing that many of them need an access to the HW peripherals. Of course, locking other cores while accessing the peripheral is not an option, like enforcing all ASW components with HW interface to be integrated on one same core.We will explain how the BSW itself is distributed, and how the access to the peripherals from different cores is made possible. We will explain the paradigms used in the design of the BSW, as well as the main cross core communication principles. Furthermore, we will describe a concept of core abstraction, allowing to share even the same task architecture between projects based on different controllers.Finally, we will propose a qualification of the BSW into 3 multicore conformance classes. In the highest level (MCC3), the ASW can be freely integrated in so called System Events, independently of any core consideration

Engine management software dynamic architecture versus integration

International audienceVariability, hard real time, increasing functional complexity (due to emissions and driveability standards), limited hardware (HW) resources : these are some of the – sometimes antagonistic – constraints a modern Engine Management Software (EMS) has to deal with. In addition, to face the price reductions in the automotive electronics industry, an intensive reuse strategy is deployed, based on a platform architecture and a component based development, despite the high functional coupling between those components, characteristic to the engine management area

Shared SW development in multi-core automotive context

International audienceWe present a methodology for the common development of combustion engine control Software between TIER-1 supplier and OEM. The classical approach of shared development used in single core projects has to be adapted to the new challenges of integration and protection, in the multi-core context. New integration and protection constraints are specified at design time, which are considered at integration and protection time. A common integration step is defined, where interfaces and constraints at the border are agreed. After that, each part can be modified and protected independently, enabling parallel developments by the partners

Early WCET Prediction using Machine Learning

ISBN : 978-3-95977-057-6International audienceFor delivering a precise Worst Case Execution Time (WCET), the WCET static analysers need the executable program and the target architecture. However, a prediction (even coarse) of the future WCET would be helpful at design stages where only the source code is available. We investigate the possibility of creating predictors of the WCET based on the C source code using machine-learning (work in progress). If successful, our proposal would offer to the designer precious information on the WCET of a piece of code at the early stages of the development process

From Relevant High-level Properties to WCET Computation Improvement

International audienceThe scheduling of real-time systems requires knowing the Worst Case Execution Time (WCET) of their tasks. WCET analysers compute timings by analysis of the low level behaviour of the target task. This document presents improvements in the WCET computation allowed by taking into account high level behaviours of the tasks. We first classify high level knowledge according to the relevance with respect to WCET estimation. We then propose a systematic method to bring this information back to the low level on which operate most WCET analysers. This approach separates the concerns of stating properties, integrating properties and computing a WCET aware of these properties

Identifying Relevant Parameters to Improve WCET Analysis

Highly-configurable systems usually depend on a large number of parameters imposed by both hardware and software configuration. Due to the pessimistic assumptions of WCET analysis, if left unspecified, they deteriorate the quality of WCET analysis. In such a case, supplying the WCET analyzer with additional information about parameters (a scenario), e.g. possible variable ranges or values, allows reducing WCET over-estimation, either by improving the estimate, or by validating the initial estimate for a specific configuration or mode of execution. Nevertheless, exhaustively specifying constraints on all parameters is usually infeasible and identifying relevant ones (i.e. those impacting the WCET) is difficult. To address this issue, we propose the branching statement analysis, which uses a source-based heuristic to compute branch weights and that aims at listing unbalanced conditionals that correspond to system parameters. The goal is to help system-experts identify and formulate concise scenarios about modes or configurations that have a positive impact on the quality of the WCET analysis