×

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!

Category Archives: Autosar

  • June 28, 2022
  • 0

Development of AUTOSAR Compliant FLS Driver Development and FLS Configuration Tool

Category : Autosar , Product Engineering

About the Customer

Our customer is an automotive tier-1 company having a diverse range of automotive solutions including emissions system, automotive interiors, connected car applications and more. We have a long-established partnership with the customer on multiple automotive projects.

Business Challenge

Resetting of the watchdog before the intended instance was the primary challenge the customer was facing. Operations like read, write, and erase etc. were taking longer than usual since the watchdog was getting reset abruptly.

Customer’s internal team deduced that this issue is trigged by the faulty FLS driver. The logical solution to the issue was to replace the FLS driver where main function of the application is separated with read/write and erase function. Since, the customer was migrating the entire system to AUTOSAR architecture, the FLS driver was also supposed to be developed according to AUTOSAR specifications.

In addition to development of an AUTOSAR based FLS driver, a tool was also required to configure the FLS driver as per the parameters.
 

Embitel’s Solution

Upon carefully going through the system architecture, Embitel’s AUTOSAR team inferred that developing the FLS driver based on AUTOSAR specifications would resolve the watchdog timer reset issue.

The gap analysis of the existing FLS driver showed us that the function to reset the watchdog timer was not being triggered in the intended manner. We used this insight to develop the FLS driver in a way that watchdog reset function is separated from the main function. Since this function constantly monitors the time elapsed in the execution of an operation, it can reset the watchdog at the intended instance and not before or after that.

The FLS driver also must be configured for usage in a specific environment. We developed a Python based configuration tool for the purpose.

Final deliverables were as follows:

  • We developed the FLS driver as per the AUTOSAR specifications provided by the customer so that all AUTOSAR compliant modules are in complete sync with each other, especially the QSPI driver which interacts directly with our FLS driver.
  • A Python-based tool was developed to configure the FSL driver as per the specifications. Since AUTOSAR code is generally static, it needs to be configured for modules like FLSS driver. Configuration items like APIs need to be enabled/disabled and parameters etc. need to be set according to configuration strategy.

FLS Configuration Tool

In addition to FLS driver and FLS configuration tool development, we also supported the customer in the integration process of FLS driver with other modules of the system.
 

Embitel’s Impact

Our FLS driver was able to resolve a major issue related to watchdog timer which was pulling down the efficiency of the entire solution. We were able to develop the tooling solution along with the driver in the provided time-frame which aided in faster turn-around time for our customer.
 

Tools and Technologies

Python: Used to build the FLS driver configuration tool

Compiler: IAR Embedded Workbench IDE
 

  • November 24, 2020
  • 0

Development of AUTOSAR MCAL Drivers for a Smoother Transition to AUTOSAR Paradigm

Category : Autosar , Product Engineering

 

About the Business Use-Cases

  • Microcontroller Abstraction Layer drivers access the on-chip peripherals functions such as CAN, Ethernet, General Purpose Timer, Watchdog, SPI, DIO and a few others.
  • This AUTOSAR layer makes the upper software layer independent of the microcontroller unit by acting as an interface between them.
  • These drivers are specific to the Microcontroller Unit.

 

Business Challenge

While developing our proprietary Body Electronics reference design, our development team realized the importance of making few of its modules AUTOSAR compliant. The body control module reference design was powered by a Renesas RH850 microcontroller; therefore, the process of AUTOSAR compliance had to begin with the creation of necessary MCAL drivers for the Renesas MCU platform.

These drivers were crucial for achieving reduced turnaround time for AUTOSAR projects where the customers wished to migrate their prototypes to a Renesas platform with full-fledged functionalities.
 

Embitel Solution

In the 1st phase of AUTOSAR implementation, the AUTOSAR team took up the task of developing the MCAL drivers required for CAN communication. Our development team identified the MCAL drivers that were required for successful CAN communication. As CAN bus protocol is primary for inter-ECU communication, our team decided to build the MCAL drivers for CAN in the first phase.

autosar-mcal-software

 

The 5 AUTOSAR MCAL drivers that were taken up in the 1st phase of AUTOSAR implementation are:

  • General Purpose Timer (GPT): Performs timer count by using on-chip MCU timer
  • Controller Area Network (CAN): Initializes CAN and performs CAN input and output
  • Microcontroller Driver Specification: Accesses MCU power and clock unit
  • Port Driver Specification: Initializes the whole port structure of the microcontroller and allows configuration of different functionality on each port and port pin
  • DIO (digital input/output) Driver Specification: DIO drivers provide services for reading and writing to/from DIO channels, DIO ports and DIO channel groups

 

Embitel Impact

  • Ready-to-integrate MCAL drivers can reduce time-to-market for AUTOSAR compliant automotive projects by 10-12 weeks.
  • These MCAL drivers would also help our prospective customer migrate from an existing BCM prototype to a full-fledged BCM solution using our BCM reference design. Since the MCAL drivers are independent of the application layer, they can be easily ported for any kind of applications ranging from Powertrain, Motor Controller for Electric Vehicles, Infotainment system and more.
  • More than 40% of the MCAL driver source code, requirements, test plans and work products can be re-used while migrating them to a different Microcontroller family such as NXP, TI, Fujitsu and others. This would also lead to reduced turnaround time for the customers.

 

Tools and Technologies

  • Microcontroller: Renesas F1KH-D8
  • Compiler: IAR Embedded Workbench IDE
  • July 13, 2018
  • 0

Complex Device Driver Development for AUTOSAR Compliant Powertrain ECU

Tags :

Category : Autosar , Product Engineering

 

About the Customer

Our customer is an Electric Vehicle OEM, based out of India. They have been pioneering the Electric Vehicle revolution in India with their wide range of products in passenger and utility vehicle segment.
 

Business Challenge

The customer had designed an AUTOSAR 4.0 compliant Powertrain ECU (Electronic Control Unit). Following software modules had been designed, as part of the AUTOSAR layered architecture:

  • An application layer

  • RTE (Run Time Environment), and OS,

  • Base Software Module (BSW) and MCAL.

However, at a later stage need was felt for the addition of a few new hardware components in the powertrain ECU like speed sensors, and Real Time Clock (RTC), I/O expander, H-Bridge etc.

These newly integrated components were required to communicate with the microcontroller. However, these hardware components had to be kept separate from the AUTOSAR software architecture due to challenges such as

  • Speed constraints with I2C channel.

  • No specification provided by AUTOSAR to interface components like RTC etc.

Hence there was a need to develop Complex Device Divers (CDD) for the Powertrain ECU

In a nutshell, our customer’s EV (Electric Vehicle) team was confronted with the following challenges

  • Design and development of the Complex Device Drivers (CDD) for the specific devices.

  • Configuration of the interface between CDDs and the AUTOSAR application layer through SPI and I2C channels.

  • Development of the APIs to enable transfer of data between the application layer and CDD.

 

Embitel’s Solution

Our Automotive Team’s job was clearly cut out, as the customer had already built the AUTOSAR layer with base software module, application layer and MCAL.

We started by developing the Complex Device Drivers for each of the devices required by the customers and proceeded to the APIs development.

Here is the complete solution that we successfully delivered for the Electric Vehicle OEM:

  • Complex Device Drivers (CDDs) for the required hardware components

  • I2C and SPI channel configuration for application layer and CDD communication.

  • Functional specification (APIs): Configuration of list of signals required by the application to control the non-AUTOSAR hardware devices.

  • Documentation of the APIs and the parameters for data exchange between two layers.

Powertrain ECU

As per our established software delivery process, we provided the design documents (software architecture) as well. This would help our customer to understand the architecture and enhance the software in future.
 

Features of Complex Device Driver Solution from Embitel

  • Solution developed based on AUTOSAR 4.0 Specification

  • Programmers guide for the configuration of the driver

  • AUTOSAR ARXML for Configuration

  • Test Specification, Verification and Test Reports Generation

  • Configurability in multiple variant of the same hardware

 

Tools and Technologies

  • TI microcontroller platform

  • Code composer IDE

  • Vector DaVinci Configurator tool

  • Vector CANoe- Simulation tool

  • XDS 100v2 Debugger
  • April 14, 2015
  • 0

AUTOSAR Compliant ECU Software Development

Tags :

Category : Autosar , Product Engineering

 

Business case brief:
  • ECU controls Camera position located at front and rear, thus controls front and rear view of the car AUTOSAR compliant ECU software developed with model based tool chain

 

Business case details:
  • Software architecture created using DaVinci Developer tool
  • Each software component modeled in TargetLink 3.1
  • Automated production code generated from TargetLink 3.1
  • Geny tool used for configuration of basic software (platform dependent)
  • ECU Diagnostic over Autosar CAN transport protocol as per UDS protocol
  • Application software tested using MIL and SIL test method
  • Functional Test vectors created using Signal generator
  • MATLAB V&V tool box used for functional and structural testing of application software

 

Tools & technology:
  • MATLAB / Simulink / TargetLink
  • DaVinci Developer
  • Geny
  • MATLAB Verification & Validation
  • April 14, 2015
  • 0

Adaptive Light Control – Passenger Car Application

Category : Autosar , Product Engineering

Business case brief:
  • Model based development of Adaptive light control System algorithm for passenger car with stepper motor control for head light unit
Business case details:
  • Model based application development
  • Two stepper motors to control head unit in the horizontal and vertical directions.
  • Communication between ALCS and the various Stepper motor controllers is carried out via LIN bus.
  • Followed MAAB guidelines for modeling
  • Code generation using RTW
  • SIL and MIL testing
Tools & technology:
  • MATLAB, SIMULINK , STATEFLOW, RTW
  • April 10, 2015
  • 0

AUTOSAR MCAL (Microcontroller Abstraction Layer), BSW and RTE integration

Tags :

Category : Autosar , Product Engineering

Business Challenge:

Our customer, a Germany based Automotive Supplier, was in search of a trusted embedded software development partner.

After diligent research and analysis, our customer had decided to pursue this project of porting the existing Battery Monitoring ECU (Electronic Control Unit) ECU software on a new microcontroller platform.

And, they also wanted to collaborate for the migration of legacy ECU software to AUTOSAR layered architecture.

AUTOSAR Migration would enable the Automotive Supplier to leverage following benefits of well-defined layered software architecture of AUTOSAR 4.0:

  • With plug and play architecture of AUTOSAR, the future enhancements and advanced ECU feature development will be independent of the underlying hardware platform, AUTOSAR BSW, RTE and AUTOSAR MCAL layers.
  • Since AUTOSAR 4.0 facilitates the shift in ECU design approach from coding to configuration. Customers can pursue ECU feature enhancements through AUTOSAR Application layer development.
  • AUTOSAR 4.0 also provides flexibility to customers in migrating to new hardware platforms by re-using the AUTOSAR complaint software components.
  • Similarly, the existing AUTOSAR software components can be easily integrated with completely different line of products designed on different hardware platforms.

 

The legacy software challenge:

Our customer had concluded to retain some specific software components and algorithms of the legacy software of the ECU.

This decision was arrived at considering the fact that these specific components have had stood the test of time throughout the lifetime of the Battery Monitoring ECU product line and were still very relevant and well-defined.

This increased the complexity of the software development project as the architecture needed to support both AUTOSAR complaint and Non-AUTOSAR complaint software components.

Partnership for AUTOSAR Software development project:

The Germany based Automotive Supplier decided to partner with Embitel Technologies, Bangalore, India since we have a dedicated and experienced team of AUTOSAR software developers. Our following expertise and project experience was very critical for the success of this AUTOSAR project:

  • Expertise in AUTOSAR MCAL (Microcontroller Abstraction Layer) development.
  • Expertise in AUTOSAR configurator tools like COMASSO, Vector Da-Vince Configurator and Developer, ECU Spectrum and KSAR tools.

 

Embitel Solution:

This successful AUTOSAR software development partnership kick started with series of technology and business workshops.

Our team of automotive domain experts, AUTOSAR software developers and project managers participated in workshops to understand the Battery Monitoring ECU product line, the legacy software architecture, various software modules and the hardware platforms.

Our automotive AUTOSAR development team collaborated to deliver the following comprehensive solution:

  • Re-designing of the existing software architecture of the Battery Monitoring ECU for seamless integration with the AUTOSAR layered architecture and also support the Non-AUTOSAR complaint software modules.
  • Design and development of AUTOSAR MCAL components for migration to the new hardware platform
  • Support for customized configuration and code generation using COMASSO tool.
  • Complex device drivers were developed to support the Non-AUTOSAR complaints software modules.
  • Integration of AUTOSAR BSW, AUTOSAR RTE and MCAL.
  • AUTOSAR testing services: Individual module testing for MCAL layer, integration testing and unit testing.
  • CANoe (a Vector tool) was used for module testing of AUTOSAR MCAL.

 

Embitel Impact:

  • This challenging AUTOSAR migration project was delivered within the desired time-lines and costs. This ensured reduce time-to-market and development costs for the Automotive Supplier.
  • AUTOSAR complaint ECUs’ has become a necessary requirement for majority of the Automotive OEMs’. Hence, the success of this project had a long-term positive impact on the various business engagements of our customer.

Archives

Contact Us

© 2018 Embitel. All Rights Reserved