The disruption occurring in the automotive industry is creating an increased desire for innovation that, in turn, is dramatically increasing software content within vehicles. This innovation is happening in autonomous drive, Advanced Driver Assistance Systems (ADAS), digital cockpit technologies, vehicle electrification and many more. There are several key trends currently affecting automotive electronics which are causing increasing demands in compute platform requirements, changing vehicle architectures and highlighting the importance of security and functional safety. With these new challenges come numerous opportunities, but in order to take advantage of these, it may just require a shift in thinking and a more holistic hardware/software approach to automotive design.
Firstly, the development of ADAS and a move towards further autonomy is dramatically increasing the amount of processing and data flow in the vehicle. In addition, In-Vehicle Infotainment (IVI) systems are becoming much more complex and feature-rich whilst driver information systems, such as modern digital instrument clusters, heads-up displays, and mirror replacement by cameras, will all require displays that will significantly change the design of the cockpit. Finally, electrification is also bringing additional processing requirements, including motor control and monitoring capabilities for the management of on-board energy and battery storage.
These trends are rapidly changing vehicle design requirements and architectures thus also impacting software requirements.
Increases in functional requirements of software allows vehicle software architects to consider new types of software workloads. Changes in vehicle architectures along with feature-rich silicon platforms, presents vehicle architects the opportunity to consolidate functionality. Architects and system integrators have the flexibility to consolidate onto one ECU functions that were previously on separate ECUs. Virtual ECUs are slowly becoming more common. Virtual ECUs are supported by proven embedded real-time virtualization solutions. These real-time virtualization solutions provide strict separation between these virtual embedded applications.
Some ECUs have functional safety requirements which necessitate a more rigorous software development process to meet the ISO 26262 standard. Functional safety is a system challenge that needs to be addressed early on in the design process of the system. Read our recent Arm blog on: The importance of building functional safety into your design right from the start to find out more on this. When OEMs develop specifications for an ECU or for a platform that will consolidate multiple ECUs, they will specify the required Automotive Safety Integrity Level (ASIL) for those functions and ultimately will influence the design of a platform or system, from a functional safety perspective.
Several workloads in the vehicle have the requirement for a connected vehicle. ADAS features, telematics, and infotainment can all require connectivity outside the vehicle. These features are often supported by different Tier 1 suppliers. OEMs may also design the vehicle architecture such that these features are supported by more than one vehicle to cloud network connection. Multiple network connections increases the attack surface for vehicle security vulnerabilities.
Security requirements are drastically increasing in the vehicle due to growing connectivity requirements. This involves numerous elements. Intelligent vehicles will now need security far beyond securing the physical networks on a vehicle. Two-way security will become a focus of importance to prevent vulnerabilities caused outside the vehicle as well as within it - this will bring new challenges of complexity and scalability.
Gone are the days of updating software on an ECU at a vehicle service centre. In the modern day of electronics, it’s expected that ECUs will be updateable OTA. This feature is expected to be on all modern-day compute platforms and considering it has been available on a cell phone for over 10 years, the same should be true for ECUs in a vehicle.
There are changes happening already in software development within the IVI space, where more and more OEMs and Tier 1s are adopting Open Source Software. Although Linux has been used in this space for some time, it’s not something that is noticeable when the vehicle starts and the IVI system boots. In a recent Automotive Grade Linux all member meeting, there was a presentation where someone counted over 15 Linux distributions currently being supported by automotive manufacturers. Over time, that will decrease, and many of these will converge onto the use of Automotive Grade Linux. Android OS is also seeing huge traction in IVI. In addition, there are some Open Source Software elements that have been developed with the rigour required to support functional safety use cases. These software elements offer functional safety solutions in the area of safety separation for virtual ECUs and Real-Time OSes that support real-time ECU workloads.
Over time, there will be an increase in adoption of Open Source Software elements by software system integrators and software distributors as part of production solutions. There is no single approach on how to adopt OSS elements to meet the requirements of safety use cases. The obvious advantage of using OSS that has the pedigree to support safety use cases is the initial low cost of entry. An ECU with safety requirements must be composed with certifiable hardware and software elements with artifacts to support the safety use case. The cost of developing these artifacts, support for certification and long term-support is what requires system integrators/distributors to charge a fee for the supported safety certified version. Simply put, investing in previously certified or certifiable software elements is a risk reduction. This is why commercial products in this space are the most popular. It is possible that in the long term we may see the automotive industry adopt more OSS elements with functional safety pedigree to support ECUs with safety requirements.
Proprietary or commercial software vendors are the most common providers of software elements to address functional safety requirements. So today, for designing an ECU that requires safety certification at the system level to ASIL D or even ASIL B requirements, most likely this work would be done with a commercial OS vendor with experience in safety certification. In the short-term, and possibly for quite some time, there will be a huge reliance on software partners that have those software solutions and previously certified software elements such as hypervisors and RTOSes.
Lastly is the long-term support requirement. With the increasing amount of software required, the more software there is to be updated. Buyers of cars will expect their cars to continue to be fully functional which means OEMs will have larger long-term support requirements.
Increases in capabilities and features in vehicles is driving increasing demands in compute platform requirements. Requirements to support automated driving features significantly increases the real-time compute requirements and connectivity to sensors. This is driving OEMs to consider how vehicle architectures are implemented. Along with the increased compute requirement comes the ability of the compute platform to support the functional safety and security requirements at the system level.
More complex systems and the increase in data movement in the vehicle has forced OEMs to take a hard look at their vehicle architectures. Modern vehicles use several in-vehicle networks for ECU to ECU communication. These legacy designs have evolved over time but now there are huge increases in performance requirements in addition to crucial lower latency requirements needed to support new applications. This forces OEMs and Tier 1s to start rethinking the ways they architect the vehicle networks and start taking a more holistic approach. There are varying ways to achieve this. Some OEMs and Tier 1s are thinking of a more centralized compute platform, some are considering more distributed architectures, but most will likely land somewhere in the middle adopting some elements of a centralized and some elements of a distributed architecture. Simulation at the vehicle level will play a huge role in reducing risk in the integration process.
Composing a system to meet the security and safety requirements drives a more comprehensive and rigorous development effort. Functional safety requirements must be considered as an engineering practice, implemented at the lowest level all the way up to the system level, both from a hardware perspective and software perspective.Security development practices must also be implemented as an engineering practice for any new development.
Arm’s software ecosystem partners offer a range of solutions and services to address these challenges in the software stack, at any level on an ECU.
Figure 1. Elements of an ECU software stack
These include solutions from the lowest level (trusted firmware) to the top level which includes partners who provide engineering services to develop applications with the rigor required for safety certification. Arm’s ecosystem of partners support software solutions and services at any one of these levels (see figure.2 below).
Figure 2. Arm partners that support solutions and/or services on different levels of an ECU software stack
Many software partners offer both safety certified and non-safety certified software elements. Safety certified solutions are referred to as a “safety element out of context” (SEooC). This is a way for a Tier 1 or suppliers to reduce risk. It allows an integrator to compose their system with a previously certified software element which will provide guidelines on how to use in a system. These are sometimes referred to as “assumptions of use”. This will provide you with huge confidence that you will pass the required safety certification at the system level.
Using experienced software partners can help reduce development costs. Arm’s software ecosystem partners can help address challenges encountered when composing a system that includes software stack elements. They have experience in integrating their software elements in both safety certified and non-safety certified designs. For example, at the embedded virtualization level some partners provide Type-1 hypervisor solutions whilst others have microkernel approaches to solve the challenge to create an environment to run a virtualized real-time workload. Both the Type-1 hypervisor solution and the microkernel approach provides safety separation between virtualized workloads.
One of the biggest advantages of the Arm ecosystem is the number of options for silicon platforms. An OEM or Tier 1 always have multiple options for a silicon platform. It is very common for ecosystem software solution partners to support platforms from multiple silicon partners. The ability for software solution partners to support more than one hardware platform supplier is a great advantage. Many of Arm’s solutions are adopted and used by silicon partners. Many silicon partners who have solutions in the automotive space are listed in our Arm Automotive Developer Community (AADC), some of which include MediaTek, NXP, Renesas, Telechips, Xilinx and TI. The software partners listed here do a great job in supporting Arm technology and showcasing a holistic solution. Some of the solutions may require a small adjustment or customization to the board support package for the platform but in general, any Arm silicon platform could be supported by any of the software platform providers.
With trends in automotive electronics dramatically affecting software development, the requirement demands of software will only increase. These requirements are affecting the way the vehicle architectures are being implemented so OEMs need to start thinking about having a more holistic approach to vehicle architecture. Arm and its ecosystem of software partners can address any level of the software stack to help deliver a complete solution.
To see our full list of Automotive software partners please visit our Arm Automotive Developer Community page.
[CTAToken URL = "https://developer.arm.com/markets/automotive/arm-automotive-developer-community/automotive-ecosystem-partners?utm_source=Arm%20Community&utm_medium=Blog&utm_content=Automotive%20software%20development%20-%208%20disruptive%20trends target="_blank" text="Visit AADC" class ="green"]
If you are an automotive product and/or services company and would like to showcase your solutions that support Arm, we invite you to visit the AADC membership link to inquire how you may become part of AADC.
[CTAToken URL = "https://pages.arm.com/automotive-developer-community.html?utm_source=Arm%20Community&utm_medium=Blog&utm_content=Automotive%20software%20development%20-%208%20disruptive%20trends target="_blank" text="Become an AADC member" class ="green"]