Autonomous driving, connected vehicles, power electronics, infotainment and shared mobility are some of the developments which have mobilized the revolution within the automotive industry in recent years. Combined, they are not only disrupting the automotive value chain and impacting all stakeholders involved but are a significant driver in the growth of the automotive software market which is expected to cross $450 billion by 2030. Unfortunately, these rapid changes are making it difficult for automotive OEMs and other industry stakeholders to keep pace. This is partly due to the fact that a large part of these automotive innovations depends more on software quality, execution, and integration as opposed to mechanical ingenuity.
Despite the importance of software in the cars of today, the development of the embedded software modules is often either done in isolation, partnerships or sometimes bought from suppliers. These modules are then stitched together into a proprietary platform. But these proprietary platforms are difficult to support as the hardware supplied needs to work seamlessly with the platforms.
To ensure configurability, flexibility and maintenance for the hardware defined cars of today, there is a growing need for standardization of software defined transportation platforms. With the increasing complexity of hardware and software, it also becomes necessary to find common solutions across product lines. The Automotive Open System Architecture (AUTOSAR) is a big step in this direction and founded by companies such as Toyota, BMW, VW, Ford, Daimler and GM with the aim of standardizing the software architecture for the automotive industry. AUTOSAR enables hardware and software development to be independent of each other and makes it easier to implement the growing complexity, quality and reliability of the electronic systems used in the automobiles. This standardization has helped the automotive embedded developers in focusing primarily on the innovations in the product feature development rather than working on different architectures making it easier to reuse applications between ECUs. The open source AUTOSAR architecture has been adopted by several companies who in turn have given it their own flavor. These include companies like Vector, Elektrobit, Bosch etc. to name a few.
To provide flexibility to software developers, AUTOSAR has been developed using a layered approach to software development with the complete software split into multiple layers such as Application layer, Runtime environment and the Basic software. The Basic layer in turn has further been broken into the Services layer, the ECU Abstraction layer and the Microcontroller Abstraction Layer (MCAL).
The device drivers for the MCU are developed using the standard as specified in the Microcontroller Abstraction Layer which provides inputs to the software developer about the name of the API, the parameters of the said APIs and the overall functionality of the driver. The primary benefit of standardizing the APIs is that the MCAL drivers which have been developed can be reused across multiple customer projects by the OEMs as well as across multiple Basic Software Layers (BSWs) provided by multiple vendors. This results in reduced development times for the OEM as well as less integration efforts on the part of the SW Integrator. Consequently this leads to reduced time to market resulting in huge cost reductions for the OEMs.
How are MCAL device drivers any different?
In the automotive industry, there is a general understanding that the suppliers will supply the MCAL layer to be placed on the register level of the microcontroller. While reference implementation of MCAL may be provided by some suppliers, there is a big chasm which needs to be crossed in order to develop a production ready implementation. One of the major challenges faced while developing the device drivers is the rather complex interaction between specifically implemented hardware features and standardized software requirements. The device driver solutions also need to map the different software modules to the same microcontroller resource and need to manage the complex dependency between software driver configurations.
Moreover, anyone who has developed drivers or used a driver knows that the driver comprises of APIs which take certain parameters as defined by the driver developer. The application developer uses the developed APIs when developing applications to achieve a pre-defined functionality. While this is true in the case of AUTOSAR as well, and most of the APIs accept parameters which are passed by the application developer, there is another side to the AUTOSAR development process which deals with configuration of the MCAL.
The configuration of the MCAL is done using a Module Configuration Generator (MCG) which generates a configuration which is then given to the driver for it to configure the hardware as mandated during the configuration process. The configuration can then be used across multiple hardware platforms for the same microcontroller.
MCAL also requires an adherence to strict quality standards and considerations and defines how the drivers should be written. They have to be MISRA compliant and meet the necessary safety requirements (ISO26262). These include for example when to clear the allocated memory or ensuring parameters are not passed using pointers to ensure safety critical programming.
The development of the MCAL for different ASIL levels also possesses its own challenges. ISO26262 specifies particular processes and methodologies to be followed during the development of the MCAL drivers for different ASIL levels which often end up modifying the architecture of the MCAL driver. Some of the design changes to the MCAL driver can potentially include
- The number of safety checks done in the driver. These include aspects such as monitoring of errors during register accesses, monitoring memory corruption, addition of safety markers to the configuration data etc.
- Implementation of safety mechanisms needed in the event of errors during register accesses.
- Memory partitioning has to be done such that variables of an ASIL-D driver (highest level of ASIL) do not occupy the same memory space or overlap as the variables of an ASIL-A driver (lowest ASIL level). This partitioning is done during system and software design.
Complex drivers
The complex device drivers are also a part of the AUTOSAR architecture and includes developing and integrating a driver, which does not need to conform to the AUTOSAR standard, into the BSW. As such the developer is free to architect their own driver with the APIs, parameters and functionality for the APIs according to their choice. But developing a complex driver is easier said than done as complex driver implementation often requires awareness of overall system constraints such as timing and latency requirements.
Our expertise
Vayavya Labs, with its considerable experience in the embedded domain, AUTOSAR and MCUs, provides an avenue for design companies to leverage their expertise for custom driver and software development for the automotive industry. It has successfully implemented MCALs for multiple hardware platforms across multiple OEMs such as Synopsys’s ARC HS3x and EM6 processors, Calterah’s Alps 77GHz Radar SoC, NXP’s MPC5748 controller to name a few. It has also developed MISRA compliant drivers for Spi, Qspi, Ethernet, Can, Can-FD, Mcu, Port, Dio, Pwm, Gpt, Adc modules.
Vayavya Labs also provides a software platform – DDGEN – to automatically generate MISRA compliant device drivers for commonly used peripherals to ensure rapid development of automotive applications.
Also Read:
CEO Interview: R.K. Patil of Vayavya Labs
A Blanche DuBois Approach Won’t Resolve Traffic Trouble
Chip Shortage Killed the Radio in the Car
Share this post via:
The Data Crisis is Unfolding – Are We Ready?