Monthly Archives: July 2020

Is Adaptive AUTOSAR Here to Disrupt the Way Automotive Software is Developed?

In our previous blog, we compared the Classic AUTOSAR with its Adaptive counterpart. The idea was to highlight the need of the adaptive platform and to bring out the key differences between the two.

In this second blog on the Adaptive AUTOSAR series, we take the discussion forward by delving deeper into the Adaptive AUTOSAR platform.

Reports suggest that by 2025 more than 65% of vehicles will comprise electronic components, and software forms a major chunk of it. Not only does the software grow in number but also in complexity. Additionally, there are functional safety requirements to be fulfilled for the safety relevant components.

Adaptive AUTOSAR platform has been designed considering these requirements. So, you get more computing prowess, highly flexible software configurations and communication managers. That’s not all! The transition from multi-core processors to their advanced successors, from CAN to Ethernet/SOME IP, and Embedded C to C++ are some of disruptions the adaptive platform is likely to bring about.

Curious? Let’s cut to the chase!

What is AUTOSAR Adaptive Platform?

In the simplest terms, AUTOSAR adaptive platform is a set of mechanisms that implement the runtime for the Adaptive Applications. What we call software components in the Classic AUTOSAR environment, are termed as Adaptive Applications.

The adaptive platform offers a flexible environment where the applications can be added or modified by the ECU acting as a central server. Updating the software has become all the more important as it interacts with an ever-changing environment. Case in point- ADAS, which takes data from the surrounding infrastructure and processes it to assist the driver to drive better and safer.

AUTOSAR adaptive is based on POSIX operating system. It is one of the pre-requisites of using complex processors and offers developers the necessary building blocks to create high-performance automotive applications.

What makes this new platform ‘adaptive’ is the AUTOSAR runtime. This runtime environment essentially provides the interfaces required to integrate different applications in the ECU. These applications need not be integrated to the ECU at one time. As the name suggests, the adaptive applications can be integrated at runtime. This implies that different software can be developed and distributed for an ECU, completely independent of each other.

At the heart of an AUTOSAR adaptive platform, there is an POSIX operating system and each adaptive application is implemented as a process in this OS.

We will discuss the POSIX OS and the intricacies of the adaptive platform in the subsequent sections!

The Emergence of Intelligent ECUs

One of the major factors that has triggered the development of the adaptive AUTOSAR platform is the emergence of automotive ECUs that not only communicate within the in-vehicle network but beyond.

Popularly called Intelligent ECUs, these control units are different from the conventional ECUs in many aspects including time-constraints, safety requirements and frequency of updates.

For instance, in a V2X implementation, a vehicle ECU communicates with the outside infrastructure which is constantly being modified/upgraded. The application inside the ECU also needs to be updated in order to avoid any incompatibility issues.

Moreover, such implementations also require Machine Learning, dynamic loading of software components, use of existing libraries for data analysis and so on.

In addition to collection of the data, some of these sets of information also need to be displayed to the users on an infotainment system or a head-up display. Afterall, these are features that make an intelligent ECU.

Developing such intelligent ECUs and integrating them in a vehicle network influences the network architecture of the vehicle as well as the other conventional ECUs that communicate with them.

• The first requisite of a vehicle network to support such ECUs is high data throughput rate with minimum latency.
• Secondly, the development environment should be such that it allows software functions to be added to an ECU even after the production has started.
• Moreover, the environment must support software from third-party technology providers.

Considering all of this, it is a no-brainer to deduce that a dynamic software integration environment is what the future vehicles would require.

So how does AUTOSAR Adaptive Platform (AUTOSAR AP) achieve this? Let’s find out.

Modern Problems Require Modern Solutions

Essentially, AUTOSAR AP provides an environment that is capable of supporting high-performance computing prowess and offers flexible configuration for dynamic integration of software.

AUTOSAR AP is able to achieve this feat by two major technology accelerators- Ethernet and Multicore Processors. Complex ECU operations in applications such as ADAS and Over-the-Air (OTA) update require higher bandwidth; something that conventional CAN protocol cannot achieve. Ethernet solves this issue by offering higher bandwidth which enables accurate transfer of large messages and point-to-point communication, among others.

Higher bandwidth needs a match in terms of computing prowess, which is generated by multicore processors powered by hundreds of cores. Classic AUTOSAR platform does not support such multicore processors but Adaptive platform is designed to support them. The magic lies in the concept of parallel processing and heterogeneous computing.

Parallel processing is a self-explanatory term which refers to the execution of several processes in parallel.

Heterogeneous computing is a process to combine several computing resources like multicore, GPU (Graphic Processing Unit), etc.

We will talk about these concepts in detail in our next section.

Salient Features of Adaptive AUTOSAR that Make it Indispensable in Modern Times

There are certain features that make AUTOSAR Adaptive Platform what it is. Let’s explore them!

1. Service-Oriented-Architecture: Unlike the conventional ECUs where the inter-ECU communications are defined at the configuration stage, Adaptive Applications take a service-oriented architecture (SOA) approach. In the SOA paradigm, the adaptive applications make their functionalities available as services. Other ECUs in the network can request for a particular service over the ethernet network. The ECU requesting for the service becomes the client and the one that fulfills the request assumes the role of a server. It is the SOA that allows dynamic integration of a new software at run-time. And that’s what makes AUTOSAR AP so flexible.
2. POSIX (Portable Operating System Interface) Based Operating System: As mentioned earlier, POSIX based operating system is quite crucial to the adaptive platform. In order to implement the service-oriented architecture, a POSIX OS or a similar operating system is a pre-requisite. It provides a standard interface for communication between the application and the operating system. From memory allocation to scheduling, POSIX based OS makes sure that the services are distributed to the ECU network in the intended manner.
3. Parallel Processing: In an SOA environment, each running application becomes a separate service that needs to be executed under a strict time constraint. When there are multicore processors running in a heterogeneous computing environment, it is the capability of parallel processing that keeps the applications running.
4. Ethernet and Some/IP: The service oriented architecture implemented in the AUTOSAR AP is brought to life by Ethernet and SOME/IP. While the ethernet is the physical medium used for the communication, SOME/IP is the network protocol that acts as the middle layer. It defines the way in which the applications communicate with each other. SOME/IP also takes care of the serialization of the data sent over the Ethernet network.
5. C++ as the coding language: Transition from embedded C to object oriented C++ as the coding language is an interesting and a welcome change. C++ brings with it, the virtues of object oriented programming, dynamic memory management, and an extensive set of standard libraries. All these attributes make C++ a language of choice in performance-intensive algorithm development.

Explaining the Most Important Use Case of Adaptive AUTOSAR Platform: Highly Automated Driving

We have been reiterating in the blog that Adaptive platform supports the much-needed computing prowess. Automated driving is one business use-case that has requirements that can fulfilled most effectively by an adaptive platform. Why so? Because an automated car has to:

• Collect data from hundreds of sensors
• Communicate with another vehicles, traffic lights and essentially the environment around it
• Process these humungous data sets to make accurate driving decisions
• Update the software frequently at run-time; so, there is no time to take a trip to the service center for each update

At the ECU level, these functions translate to requirements beyond the capabilities of Classic AUTOSAR which is mostly hard-wired. The AUTOSAR Adaptive Platform fulfills these requirements by steering away from hard-wired communication and adopting a service-oriented architecture. The AUTOSAR runtime is completely independent of the application. The applications make use of the brokering service provided by the platform without worrying about the underlying communication protocol. As a result, software can be added or replaced at runtime.

Designed to support multicore processors, the adaptive platform utilizes heterogeneous computing to crunch the numbers real fast. Rest of the job is done by Ethernet and SOME/IP that take care of the bandwidth for faster communication.

Conclusion

Adaptive AUTOSAR is not a replacement to its Classic counterpart. In fact, they complement each other at many levels. The recent shift of the automotive industry towards automation and communication beyond the vehicle has put Adaptive Platform on center stage.

Vehicles will evolve to necessitate higher degree of processing power and flexibility, and it looks like the AUTOSAR Adaptive Platform is all set to disrupt the industry in the future.

[Vlog] How to Perform HIL Testing for Automotive Software Development

Hardware-in-loop (HIL) testing is performed at the validation testing stage. It occurs at the last stages of V-Cycle after the integration testing of the application has been performed.

At this juncture, the application is validated against the requirements based on which it has been developed.  Ideally, the application that is to be tested, is put inside an automotive ECU called the Device Under Test (DUT). During validation, the DUT must be tested in an environment where it communicates with the signals of other ECUs in the vehicle.

However, testing an ECU inside a vehicle is not a viable option as it escalates the cost enormously. Moreover, the entire target vehicle system may not be available at the time of testing this application.

HIL testing is the answer to these challenges!

Major Highlights of the HIL Testing Vlog

• Understanding the need for HIL Testing
• What is Hardware-in-loop testing?
• How is HIL Testing performed
• Understanding a HIL Test System
• Widely used HIL Test systems in automotive domain

Our series of vlogs is created to drive home complicated concepts in the simplest and most interesting way possible. These vlogs are helpful not just for automotive engineers but also for business managers who wish to learn about automotive concepts to make better decisions in their line of work.

Happy viewing!

Integration of DoIP over Linux: An Intro to the Process and Mitigation of Challenges

Diagnostics over Internet Protocol, commonly referred to as DoIP has opened avenues for remote vehicle diagnostics, ECU re-programming and more.

On the ground, it translates into safer vehicles on road, less hassle for customers who have to drive down to the service center for every issue, and better customer experience provided by the OEMs.

Traditionally, DoIP is integrated into the Vehicle ECU (Server) and external tester device (Client). Both server and client are based on Embedded systems where DoIP is integrated into the Transport Layer.

In the recent past, technology vendors have been exploring the idea of integrating DoIP on Linux platform instead of Embedded systems. This is obviously not possible inside the vehicle system as it is largely dominated by embedded systems. However, the external testing device where DoIP is integrated as the client, can be based on a Linux platform.

Integration of DoIP directly to a Linux platform where other applications also reside, can make for an interesting use-case. But there are several challenges too!

So, what are the challenges involved? Despite the challenges, is it still worth migrating to Linux platform? How do we mitigate these challenges? We will try to answer these questions in our blog.

But first let’s understand the basic architecture of the Linux platform.

Understanding the Linux Architecture for DoIP Integration

In a Linux environment, there are two realms where the different modules reside- User Space and Kernel Space. If you compare this with an embedded system, there are some visible differences.

In contrast to the Linux environment, which is divided into two layers, an embedded system will at least have 3 layers- Application Layer, Base Software Module and the Low-Level Drivers. In addition to these modules, there is a scheduler/RTOS that manages the scheduling of tasks performed by the applications.

Now let’s understand the User Space and Kernel Space of a Linux Platform:

1. User Space: This is the set of locations where the user processes run. The User Space will have the applications, the DoIP and other automotive stacks and the sockets required for stacks to communicate with the physical medium. As a matter of fact, the applications residing in the User Space have limited access to the memory. It is the Kernel that manages the applications running in the User Space.
2. Kernel Space: Kernel is the core of the Linux platform. It has access to all of the memory. In addition to providing the APIs to the applications in the User Space, it has a very important role to play in the context of scheduling the applications. It is the Kernel that decides which application will be given priority for execution and the ones that will be queued.

As already mentioned, DoIP and other stacks are part of the User Space. Why are stacks kept in the User Space and not in the Kernel Space, you may ask? Theoretically, it is feasible. However, one of the many reasons that it should be avoided is that any instance of a run-time error can destabilize the kernel and result in system crash.

The diagrams below show a clear distinction in the architecture of embedded system and Linux OS

DoIP integration as per the OSI architecture (Embedded System)

DoIP integration in Linux Environment