Multicore architecture has become an integral part of modern cars thanks to must like ADAS, V2V communication, intelligent features in your automobiles. Automotive application needs Multicore architecture to meet performance, power and design requirement. EM media presents to you this article discussing Multicore tech in automotive engineering and how does it comes out with the results.
The time has come! Multi-core microcontrollers are becoming first choice for future embedded system developments. Reasons are, among others, an increasing demand on performance and reliability of such systems. This is accompanied by continually increasing software complexity, and therefore growing development effort and time. Engineers are facing new challenges in terms of timing, data dependencies, performance, and reliability requirements, which need to be considered as early as possible in the development process of software. Although the demand for and availability of multi-core processors in the automotive industry increases, the domain-specific AUTOSAR standard for the development of embedded automotive software, due to its inherent concept for static software designs, does not efficiently solve many of the problems related to the truly parallel execution of tasks in multi-core systems. In this paper we focus on the resource sharing problems inherent to the AUTOSAR Operating System and propose the introduction of a more flexible concept. While regular AUTOSAR tasks are unaware of their resource-related impact on each other, we extend the resource manager to issue so called hints across cores to notify blocking tasks about their spurious influence on the system. This gives them an opportunity to collaborate with other tasks in order to reduce bounded and avoid unbounded priority inversions as well as deadlocks. It also improves the overall system reactivity and allows sharing the underlying hardware more efficiently. In the presented test cases, we could reduce the blocking time for spinlocks significantly, without changing the AUTOSAR API, and still keeping the system deadlock free.
There is a simple market myth for Electronic Control Units (ECUs) in the automotive market: multi-core processors offer better performance than single-core ECUs. Does this always hold true? The answer is no! Major efforts can be required to get the processor performance actually on the road, considering the peculiarities of hard real time software and the usual constraints, e.g., the overall memory consumption of the application. Application developers of today need to produce code which is error-free, and whose performance is optimized for plethora of devices. Performance of application code is studied e.g. by analyzing performance data obtained by executing application with tracing tool. Developers typically have their favorite tools which they prefer to use but unfortunately target devices are based on different computing platforms that have different performance probes which cause difficulties for using same tool with different multicore platforms. Universal Tracing Interface for Multicore Processors (UTIMP) aims to provide an unchangeable tracing interface enabling developers to perform required tracing tasks with the UTIMP, utilizing the favorite tool when possible, for different Multicore platforms. Software development for embedded multi-core processors is considered to require a large expenditure and to be difficult. The good processing speed of the multicore processors is due to the multiple cores which operate simultaneously on instructions, at lower frequency than the single core. At the same clock frequency, the multicore processor will process more data than the single core processor. In addition to this, multicore processors deliver high performance and handle complex tasks at a comparatively lower energy or lower power as compared with a single core, which is crucial factor in appliances such as mobile phones, laptop etc. which operate on batteries. Also, since the cores are fabricated close to each other on the same chip, the signals travel shorter distance between them due to which there is less attenuation of signals. Since the signals don’t attenuate much, more data is transferred in a given time and there is no need of repeating the signals. One of the biggest factors affecting the performance of a multicore processor is the level of parallelism of the process/ application.
- The lesser the time required to complete a process, better will be the performance. Performance is directly related to the amount of parallelism because more the number of processes that can be executed simultaneously more will be the parallelism. Parallelism can be considered at two levels ILP and TLP.
- TLP increases overall parallelism by breaking a program into many threads and execute them simultaneously.
- To achieve a high level of parallelism and an overall high performance, software developers must write such algorithms that can take full advantage of multicore design. In other words, all the cores should be used in the most efficient manner. If the algorithms written are not compatible with the multicore design, then it may happen that one or more cores starve for data. In such a case, the process will run on one of the cores, while other cores will sit idle. So, in a nutshell, the success of multicore technology strongly depends on the way the algorithms are written. Also, companies like Microsoft and Apple have designed their operating systems which can run efficiently on multicore configuration.
“Embedded software safety is one of the top requirements for vehicle systems designers, and our ability to merge safety-critical information from vehicle systems without compromising rich cluster graphics or functionality has been very well received by our customers,” stated Rainer Oder, general manager, Mentor Automotive.
“Multi-core & safety – working solutions on safety design of Automobiles”
Automotive safety for software and hardware is increasingly seen as an ongoing evolving process, reflected in the enhancements to standards. This long-term understanding is enabling automotive experts to account for complex situations in certification standards such as the growth of multicore processors, avionics computing, and the role of safety certification. Faster processing speeds are also a feature of multicore processors, which have brought many performance advantages to automotives. However, the complexity of the devices necessitates more verification and testing, which add to an already complex certification process when it comes to automotive systems.
“Probably the most prevalent trend today is the need to adopt multicore silicon for use in safety-critical designs. This has been a trend that’s been going on for the last five years, but one of the challenges when you use a multicore part is it’s very difficult in some cases to understand the complete behavior of those parts because they’re so complex, there’s so much functionality that’s substantiated in the part that it brings about a lot more scrutiny, a lot more tests, and a lot more verification when trying to deploy that part in a safety-critical platform,” Wind River’s Wlad says. “Some of the customers are wary to adopt multicore silicon for that reason.
Functional safety of Automotives as per ISO 26262
Implementation of the functional safety requirements stipulated by ISO 26262 is now an integral part of the development process in automotive engineering. The requirements for the functions of an ECU are assessed with respect to their relevance to safety on the basis of a hazard and risk analysis and the appropriate ASIL (Automotive Safety Integrity Level) are assigned. What are the consequences for multi-core software architecture if safety-related functions have to be implemented? Before answering this question there are a few points to note with regard to the lockstep concept for multi-core processors used in many safety projects. Multi-core architecture can be used to increase computing power or – in the case of safety-related systems – for the implementation of diversity algorithms such as ASIL decompositions. The developer assigns the software modules to the OS applications defined in AUTOSAR on the basis of parallelizability and in accordance with the safety concept. This corresponds to partitioning as defined in ISO 26262 and refers to areas within an ECU which have to be able to run without causing any mutual interference (freedom from interference). In multi-core ECUs the OS applications are assigned to the various processor-cores (Figure 1). From the point of view of the developer it is irrelevant whether the purpose of partitioning is parallelizability or decomposition: The task is to ensure freedom from interference between the OS applications. This essentially requires runtime monitoring and the avoidance of erroneous changes to memory content of relevance to safety.
Mentor® Automotive Safety Certifiable Digital Instrument Cluster solution
Mentor Graphics Corporation recently announced the availability of the Mentor® Automotive Safety Certifiable Digital Instrument Cluster solution enabling safety-critical driver information to be displayed simultaneously with rich 3D graphics on a single instrument cluster display. The software architecture is implemented on a multi-core and even on single-core System-on-Chip, and features very fast boot time. This new solution addresses a key problem for the automotive OEMs: How to migrate safety-critical driver information to full-featured, graphically-rich digital instrument clusters and comply with safety standards including ISO 26262, without pushing up hardware or safety certification costs. Automotive OEMs today design digital instrument clusters that include graphical information relating to essential warnings from the vehicle, such as icons notifying the driver of brake, engine or tire problems. The new solution, which is compatible with safety-certified Nucleus® RTOS and Mentor’s automotive-qualified Linux solutions, allows safety-critical and non-critical information to be displayed simultaneously on the same display, while maintaining isolation of safety-related functions to comply with ISO 26262 safety standards. The low-overhead isolation features of the solution are uniquely designed to enable the most efficient use of system resources to allow maximum performance of rich 3D graphics, together with complex and demanding features such as infotainment, ADAS and smartphone connectivity, all driven from the same SoC. The solution enables car makers to reduce costs because the system is built on pre-certified components such as the Nucleus® SafetyCert™ real-time operating system (RTOS), resulting in minimization of the number of lines of new code to be safety certified. It reduces silicon cost because the solution runs on a single SoC, or even a single core, and makes efficient use of available CPU resources. Mentor Automotive worked with Socionext Embedded Software Austria GmbH to integrate their CGI Studio development platform for automotive HMI with the Safety Certifiable Digital Instrument Cluster Solution. Reinhard Fuericht, general manager of Socionext’s CGI Studio BU, said, “The capability of the Mentor Automotive platform is complemented by the high-end graphics and unique mixed safety-criticality features of CGI Studio, resulting in a seamless end-to-end solution for safety-certifiable HMI from tooling to display.”
SafeAssure Functional Safety Program by NXP
A simpler way to comply with standards for functional safety at the system level is SafeAssure Functional Safety Program by NXP. These SafeAssure solutions reduce the time it takes to develop safety systems that comply with the International Standards Organization (ISO) 26262 and International Electrotechnical Commission (IEC) 61508 standard. The platform is based on The S32V230 family, designed to support computation-intensive applications for image processing. The S32V234, as part of the S32V230 family, is a high-performance automotive processor designed to support safe computation-intensive applications in the area of vision and sensor fusion. This is the first automotive vision system-on-chip (SoC) with the requisite reliability, safety and security measures to automate and ‘co-pilot’ a self-aware car. Our S32V230 microprocessors, as part of the SafeAssure program, are structurally designed to comply with stringent ISO 26262 functional safety requirements, and engineered for automotive-grade quality metrics measured in parts per billion.
Multicore Embedded System tool chain by iSYSTEM AG & Timing-Architects Embedded Systems GmbH
iSYSTEM AG and Timing-Architects Embedded Systems GmbH are announcing the availability of a tool chain that enables continuous and automated software development of multi-core embedded systems. Using the innovative simulation and optimization tools (TA Tool Suite) of Timing-Architects it is possible to improve the performance as well as the reaction times of embedded multi-core systems. With the TA Tool Suite embedded systems are developed efficiently and therefore cost effective. The TA Simulator of Timing Architects allows evaluating the real-time requirements before and during the development of software for embedded multi-core systems using a model-based approach. With the TA Optimizer manual and error-prone development decisions, e.g. the distribution of functions to the individual cores of multi-core processors, are performed and evaluated automatically. Time-consuming development iterations (re-design) are eliminated and the number of costly hardware tests is drastically reduced. The development process is faster, more flexible and cost-efficient. In addition, the hardware resource utilization, essentially the processor and memory resources, is precisely investigated and optimized. This is often the key to the development of multi-core systems and avoids project escalations.
Altium New Software Integrity Analysis Solution for Automotive Safety Applications
Automotive safety integrity levels are an absolute must to guarantee safe and reliable execution of applications in the real-time environment of an automobile. Yet developers constantly struggle with the need to partition their applications and reduce the interference between software components while still maintaining the highest safety levels possible. One way to achieve this goal in mixed criticality systems is to prove that low-level safety functions, like audio related applications, do not interfere with high-level safety functions, like braking systems. This so called ‘Freedom from Interference’ is the goal, but not an easy one to achieve in new multi-core architectures where more functions are being combined into one control unit. The TASKING Integrity Checker provides embedded software developers with the needed tools to accomplish this task, including:
- The ability to work at the compiler level so that developers do not have to change the source code in an application.
- Information about memory allocated is already included, with unique ways to identify memory write/read access.
- Information about the safety classes of functions are built into the application, allowing developers to easily address the implementation of safety requirements with ASIL aware static analysis.
By making the TASKING Integrity Checker available as a stand-alone application, embedded developers will be able to create safe and reliable automotive applications, regardless of what architecture they are working on.
“Having to balance the needs between transitioning from single-core to multi-core architectures while still maintaining industry-standard safety integrity levels, e.g. for ISO 26262 certification, is making it harder than ever to manage the software in today’s vehicles,” said Harm-André Verhoef, TASKING Product Manager at Altium. “This is why we introduced the TASKING Integrity Checker to help to identify and remove safety critical interference within automotive applications in the most efficient way possible for embedded software developers.”
AUTOSAR (AUTomotive Open System ARchitecture)
With growing success, AUTOSAR has been established as the de facto industry standard for the development of automotive E/E architectures. Furthermore, the use of timing simulation for the evaluation of a system’s behavior, especially with the introduction of multi-core systems, gets increasingly popular. The automotive industry is facing increasing demands for more sophisticated functions, e.g. comfort features, increasing safety requirements or the “internet of things” in smart electronic devices. To handle this demand, more than 100 million lines of code are mapped to many ECUs (Electronic Control Units), which can number up to about 100 units for high-end cars [1]. This number of ECU leads to an ever increasing complexity resulting in greater engineering effort, additional weight and restricted flexibility for updates and modifications. With the ongoing shift towards multi-core systems, the automotive industry has found a solution not only for counteracting this development, but also for leveraging additional processing power for new functionality. However, most existing applications cannot benefit from the new multi-core architecture without significant modifications due to the concurrent nature of the new processor technology. Therefore, multi-core has a huge influence on the complexity that has to be handled during development. Each additional core for example, increases the number of possible task allocations exponentially. At the same time, task allocation has direct effects on real-time properties, efficiency- and data-communication overhead. For that reason, over the last years, timing simulation evolved into an inherent part in the development of software systems for multi-core architectures.
AUTOSAR (AUTomotive Open System ARchitecture) is standardized software architecture for the automotive industry. One of its main goals is to enable the integration of software from different suppliers in order to increase the functional reuse. Therefore modular software architecture was defined, where software functions can be implemented independently from the underlying hardware. In AUTOSAR this decoupling is even getting to a point where the developer doesn’t have to be concerned with the final mapping of the software to the hardware e.g. while implementing the communication with other software functions or the environment. This means that from the viewpoint of software function it doesn’t matter whether its communication partner resides on the same ECU or somewhere on the other end of the vehicle as long as no timing constraints are violated. The same holds for more detailed multi-core mapping decisions. To achieve this, the individual software functions are encapsulated in so called components. Each component however can communicate with each other or the operating system only through standardized interfaces. To make this interoperability possible, the software architecture has to be configured by providing information on each software component. These required pieces of information are collected within the following AUTOSAR models
- System Configuration Description / ECU extract of System Configuration: Contains an abstract description of the software components, ECUs and system constraints in the whole system or a specific ECU respectively.
- ECU Configuration Description: Contains concrete values for all configuration parameters of the basic software including operating system and runtime environment for a single ECU
Message-based Networks-on-a-Chip (NoC) provide significant advantages with respect to temporal predictability, fault isolation and energy efficiency. However, the AUTOSAR standard for multi-core operating systems focuses only on multi-core platforms with shared memories. In order to obtain the benefits of message-based interactions, this paper maps an AUTOSAR system to a multi-core platform with a time-triggered NoC. Cores serve as virtual Electronic Control Units (ECUs), each containing a lightweight AUTOSAR operating system and a Run-Time Environment (RTE). Virtual ECUs provide meaningful units of abstraction and ensure freedom of inference from other cores. Computationally expensive functionality of the basic software is delegated to system cores, which serve as hardware accelerators for the application cores.
In order to manage the collection of the necessary information required for a system configuration, AUTOSAR also provides a description of development steps that have to be executed during system development. Consequently, models represent a fundamental part in the AUTOSAR methodology [4]. This raises the question of whether or not all the information needed for a conclusive analysis can be transformed from an AUTOSAR model to a simulation model. The available information is grouped based on the work product it can be found in. That way it is also possible to make a statement about the point in time this information is available in the development process.
Conclusion
Today’s automotives requires much from designers like functional safety and AUTOSAR is a module to design tools to design architecture for automotives especially in Multicore stricture modules.
