The Automotive industry is witnessing a constant and rapid increase in the number of Electronic Control Units (ECUs) on a vehicle: a modern car these days can easily equip up to 100 ECUs. Some of these ECUs are, in particular, dedicated to sustaining the active control of the vehicle, including, engine control, gearbox control, stability control, brake control, and many others. Active vehicle control, in turn, builds on the Hard Real-Time Multitasking Embedded Software functions, which are becoming more and more complex and are consequently requiring increased computing performance. Such growing requests for computing performance has led the main microcontroller suppliers to a radical shift in their strategy: instead of continuing to increase the performance of their single-core solutions, they are increasingly looking at architectural developments involving new families of advanced microcontrollers based on multi-core solutions.
However, two critical factors are meant to guide the development of these new products. On one hand, international regulations and standards impose stringent constraints on safety and security, thus requiring careful design of both the hardware and the software aspects of the system. On the other hand, market demands also impose an increasingly shorter time to market, with tight schedules for development and production.
The combination of these four factors (more ECUs, more complex software, stringent safety, and security constraints, and less time allowed for development) has non-negligible effects on consolidated software development standards and practice: assuring the correctness of the software integration, in terms of both functionalities and real-time performance can be challenging, owing to the shorter timeframe and the increasingly complex algorithms, communication protocols, and safety/security monitors that are mapped to the different cores available in the underlying multicore ECU.
Anticipating as much as possible the management of critical issues is the right strategy to prevent costly feedback cycles in an already onerous development process. For the development of active control algorithms, this normally results in the adoption of a simulation environment to verify the algorithm’s software behavior before creating a prototype or the real product. However, the "simulation" of the software architecture remains an open point and is also a key point for software product control because it is the only way to establish in advance, during the design phase, whether the considered mapping of the calculation units (called runnable) on the different tasks and on the cores will meet their performance requirements at run time. Then, at the other end of the development cycle, the integrated system must be validated with respect to both functional and non-functional constraints: this requires a late-stage validation phase, ideally confirming the expectations produced during the early-design analysis phase.
The MASTECS project will provide solutions for both early-stage and final validation requirements.
Early-stage analysis and design optimization
For early-stage analysis, MASTECS will provide a design-stage analysis tool that in the face of a software architecture is capable of evaluating the impact of multicore contention across different runnable-to-core schedulability solutions and data-to-memory mappings. The proposed solution, called Task Contention Model (TCM), consists of a mathematical model, tailored on both hardware and software aspects, that factors in the time budget defined for each runnable in terms of CPU time and the impact due to access to the multicore shared resources to provide early bounds on the impact of multicore interference. The TCM enables an early evaluation of both runnable/task mapping to available cores and code/data deployment and memory placement. The resulting bound son multicore interference can be exploited in view of optimizing (reducing) the amount of contention generated/incurred in the final system deployment.
Starting from an architectural description of the execution of the software of the ECUs, the TCM only requires:
- Tasks attributes (periodicity, priority, type).
- Runnable sequences associated to each task.
- Interfaces and memory profiles.
- Worst-case time budgets.
For each Software Component (COMPx) the single functions (runnables) must be characterized in terms of definition, description, and task of assignment. In addition, starting from the Software Architecture Description, a sequence of runnables (COMPx.y) has to be defined for each task.
Based on this information and on the model of the microprocessor used, the TCM delivers conservative (early) bounds on the worst-case impact of contention on the execution of each unit of analysis, which happen to be at the task or runnable level. This allows anticipating any critical issues in terms of execution and schedulability that may arise because of multicore execution. The TCM also allows making different simulations for different architectural organizations by simply acting on the exported data and changing the mapping of the runnables on different tasks/cores.
Late-stage timing validation
The TCM produces candidate configurations (runnable scheduling and data mapping) at the design phase that will be validated by MASTECS Multicore Timing Analysis (MTA) in later validation phases upon system integration. MTA solution comprises a set of technologies and tools that are deployed for the validation of the prediction models.
The proposed timing analysis framework builds on the tight integration of the Rapita Validation Suite (RVS), the market-leading timing analysis toolset by Rapita Systems Ltd., and the multicore microbenchmark technology provided by the Barcelona Supercomputing Center (BSC). Figure 2 summarizes input and outputs and data flow for the validation technologies and tools.
MASTECS MTA combines the highly automated experimental framework of RVS and a set of small, low-level benchmarks specifically tailored by BSC to generate an exceptionally high level of multicore interference during the test campaign. The MTA technology allows gathering the necessary evidence required to validate the timing behavior of the target system against domain-specific verification requirements. The validation strand of technologies and tools essentially builds on the implementation of a set of test plans on the target board and user configuration. It produces analysis results, which can be compared with the results of the predictive technologies, and certification artifacts, which can be used to develop and support certification arguments.
MARELLI expectations on MASTECS toolset
From the point of view of time-to-market, we expect MASTECS solutions to enable a big step forward in the software development process. First, MASTECS solutions will allow finding the best SW architecture mapping solution directly in the design phase without the need for prototypes to measure the effectiveness of the Architectural Design solution chosen. Another big improvement in terms of efficacy will be the high level of automation of the validation solution proposed in MASTECS to run the multicore analysis test campaign. We expect the combined solutions offered by MASTECS to enable the reduction of rework due to late detection of timing misbehaviors due to task overrun only happening during the last steps in the integration/validation phase.
