Hardware and Software architecture in vehicles in recent decades

Since the 90s, the evolution of electric/electronic architecture in cars observed an increasing demand for converting most of the conventional mechanical architectures in vehicles into mechatronic, and in some cases full-fledged electronic architecture. This rise in popularity, combined with the desire for data from the Internet accelerated its growth but also introduced the risk of exposing both vehicular and passengers’ personal data. Hardware and software capabilities emerged at the turn of the century from basic microcontroller units and software such as AUTOSAR (Automotive Open System Architecture) and JASPAR (Japan Automotive Software Platform and Architecture). Advanced research teams including US Defense, DARPA (Defense Advanced Research Projects Agency) and special interest groups like SAE started leveraging driver assistance capabilities focusing on passenger and driver safety.

This early, rapid acceptance of Driver Assistance Systems led to higher focus on data safety, leading to the addition of Functional Safety to the architecture ecosystem e.g. ISO 26262 introduced by AUTOSAR. This was mostly derived from core Safety Guidelines in IEC 61508 and its increased usage in industries and avionics like derivatives as seen in DO 178B and DO 254. Most Y2K companies also started luring drivers and consumers towards rich in-vehicle content based experiences where there were systems to provide entertainment on the go along with features such as GPS, navigational maps, etc.

OEMs and Tier-1 suppliers leveraged these developments in their ecosystems to provide futuristic acceptance of user experience in vehicles using inputs from both internal and external sources. This was done, adhering to the safety policies and regulations introduced by the government to mitigate accidents. As a result, Tier-1 suppliers and ECU suppliers started engaging more complex architectures from the semiconductor ecosystem and silicon vendors to cater to demands of data explosion. Sensors and actuator ecosystems were leveraged to keep accidents at bay, by reducing distractions caused by content and assistance rich in-vehicle controls.

In 2008, the introduction of Android phones served as an inflection point for the smartphone industry. Similarly, in the Automotive industry, an inflection point came when Tesla introduced the aggregation of data into a massively parallel ECU or an all Domain Controller with CASE (Connected, Autonomous, Safe/Secure/Smart and Electric) architecture convergence. On the other hand, conventional OEMs such as GM, Ford, Chrysler (FCA) in USA, Volkswagen, Daimler, Volvo, Jaguar Land Rover in Europe and Toyota in Japan were making hundreds of sensor and actuator associated ECUs, creating massive data handling bottlenecks. Leveraging Tesla’s success, the massively parallel hardware ecosystem evolved to cater to the needs of massive data aggregation from several OEMs/Tier-1s. This led to some crucial milestones in the history of Automotive, since the first introduction of cars by Karl Benz and Gottlieb Daimler.

Aspects of Classic AUTOSAR and the need for stringent in-vehicle management architecture

The need to handle growth in the electric/electronic ecosystem and the demand-supply of consumers and businesses saw a surge in following a strategy of plug-and-play middleware architecture with a stringent handling of real-time systems. This saw architecture such as JASPAR emerging in Asia and AUTOSAR in Europe and USA. AUTOSAR leveraged best practices of abstracting software components and application from hardware – silicon, sensors, and actuators. This was substantiated with an OSEK/VDX standard for an operating system which could handle tasks and threads considering safety-critical OS factors. The architecture evolved over time to accommodate, apart from OS, other clusters/stacks like Microcontroller, Memory Layers, Communication, Input-Output Hardware and others like mechatronics or non-compliant ones into Complex Device Drivers. With increased needs for Data and Security, newer clusters/stacks like Ethernet, Wireless Ethernet, V2X, E2E Protection and Crypto have gained traction in recent years.

The architecture clearly indicated methodologies for a safe and level playing field for the Automotive ecosystem and AUTOSAR partners to thrive by having different levels of engagement. These would be in terms of usage, contribution, and exchange of key artifacts which was based on XML called ARXML. The tooling ecosystem incorporated the need for the overall ecosystem keeping in mind all entities like OEMs which gave system description files for further downward usage. In turn, they just concentrated on system features and software component features and subsystems. The Tier-1s and integrators got the system constraint files to decouple the realization of the subsystem features in ECUs or Domain Controllers splitting domains like Powertrain (Conventional ICE), Chassis/Braking, HMI (Human-Machine Interface)/MM-T (Multimedia/Telematics), Safety (Active/Passive), and Body Control. On chip realization, silicon vendors gained domain traction to leverage hardware components required for easier single SoC realization. Sensor and actuator players played on the interaction of sensor and actuation software components, while communication and other intricacies were handled by the tool vendors with the most popular in-vehicle communication networks such as CAN, Lin, MOST and FlexRay. The ecosystem was robust and modular providing ecosystem partners with an interface to create, exchange, and reuse existing modules and artifacts.

Know more about our technical expertise in enabling autonomous vehicles with ADAS and V2X capabilities.