×

Happy to Help!

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

Great, thanks!

Monthly Archives: October 2019

  • 0

Hardware Components Skyrocketing the BOM Cost of Your Motor Controllers? Then Software is your ‘friend-in-need’!

Category : Embedded Blog

Let’s start by asking you a question! Which of these automotive products are driven by embedded software- Anti-lock Braking System (ABS), Electronic Power Steering (EPS), Seating Systems, HVAC Systems, and Infotainment System?

The answer is, each one of them! Yes, you heard it right. Even your humble car seats are now capable of storing and recollecting the last setting (positioning of the seat), give you a back massage in different ways and more.

To cut the story short, a modern-day connected and smart car can have as much as 20 million lines of source code running inside it. On top of it, 90% of the innovation in the automotive industry is now driven by the software code.

Among this mammoth stride in software capabilities in the automotive ecosystem, the system that has transformed the max is the Motor Control System.

To understand the migration from Brushed DC to Brushless DC, check out this blog – The Great Migration of Automotive OEM’s, from Brushed DC to BLDC Motors.

To find out how a Motor Control Solution works, read this blog – Automotive Motor Control System: The Brain Behind the Brushless DC Motors in an Automotive Application

Almost every automotive component that we mentioned at the onset of this blog, are driven by a motor controller solution. Whether the motor is a BLDC or an AC induction motor, motor controllers are essential in order to drive these motors efficiently.

Essentially, a motor control system is an electronic system (i.e. a combination of hardware and software components). The hardware includes Microprocessor Platform, MOSFETS, and the Electric Motor. Whereas, the software part is the control logic or the drive logic that drives the motor as per the use-case.

What is the Need to Reduce Hardware Components in any Automotive System?

As the number of such motor control systems are increasing in an automobile, the focus has now shifted to making it lighter not only in terms of weight, but also the cost.

And the most reasonable solution to this problem is to reduce the hardware component inside a motor controller. Obviously, we cannot do away with the MOSFETS or the processors, as they are the backbones. However, there are a few such components whose function can be replicated with the help of a software component.

Let’s find more about these components!

Current Filtering: Replacing a Dedicated Hardware with a Smart Software

Usually, when you run a motor with current controlling feature, current sensors and hardware component for current feedback filtering are must-have inclusions. This filtering is among the most important functionality in a motor controller, as a smooth current curve is paramount to efficient functioning of the motor.

When such current filtering hardware (essentially a circuit) is used, it has an elaborate mix of resistors and capacitors. And these components create Electromagnetic Interference (EMC effect) which again needs to be filtered.

Now to counter the EMC effect, additional circuitry needs to be included in the system. All these inclusions escalate the BOM cost, which ideally should be low.

Before, we explore how a software component manages this filtering, lets understand what exactly happens during this signal smoothening process.

A motor controller drives an electric motor with the help of Pulse Width Modulation (PWM) method, where analog signals are generated using a digital source.

The  PWM signal is defined by two attributes:

  • Duty Cycle
  • Frequency.

*Duty Cycle is the time for which the signal was on a high state. It is represented as a percentage of total time required to complete one cycle.

*Frequency measures how fast the signal switches between a high and low state

When the PWM signal is switched on, the current increases and reaches its peak before coming down, as the PWM signal is switched off.

So, when there are multiple PWM signals switched on at an instance, the current graph resembles a saw tooth (multiple current waves).

In order to smoothen the current, the current filtering hardware needs to pick the Root Mean Square (RMS) value of the current. Considering any other value of the current will not give the right output. And this RMS value will be accurate only if the duty cycle is set at the optimum level.

A hardware filtering circuitry decides this perfect time to read the current.

For instance, a 3V signal is to be created from a digital source who’s high is on 5V and low on 0V. To achieve this, the digital signal will have to be cycled at a duty cycle of 60%. Current filtering circuit and the current sensors together make sure that the current is read when the duty cycle is 60%.

i.e 60% of 5 V = 3 V

Now, for a software component to achieve the same, the logic to read the current at a duty cycle needs to be implemented.

The software will have to pick the current value in time and for that additional timers are to be put into place. The timer will read the perfect time based on the duty cycle and frequency of the PWM signal so that the output current is smooth.

Logical Steps followed by a Current Filtering Software:

  1. Start Reading the ADC Feedback Current
  2. ADC feedback value is converted to mA (milliamperes).
  3. Current is read only when the PWM is one, so to get the Mean value, we consider the Duty Cycle percentage. Eg. At Duty Cycle 60%, if we read XmA of current, mean current is 60% of XmA
  4. The filtered current is fed to the electric motor

Challenges Faced during Development of Current Filtering Software

High-end microprocessors come equipped with hardware filtering capabilities. In such scenarios, a software counterpart for current filtering is not required.

However, simple microprocessors which are most commonly used due to cost constraints, need additional signal smoothening feature.

Using a software (with necessary logic) definitely reduces the cost. But to design such software, there are certain challenges that need to be overcome.

Afterall, writing logic for such complex calculation is in itself a complicated process. Let’s have a look at some of these challenges and how do developers find the work-arounds.

Challenge 1: Reading Current at the Right Time: As the PWM signal is triggered, reading the mean value of the current is the most crucial part of the current filtering process. The time instance at which the current needs to be read by the software has to be precise and doing that is a major challenge.

The engineers overcome this challenge by assigning a separate timer, that will start in sync with the timer value of the PWM signal.

Essentially, this timer will start as soon as the PWM signal is triggered. And just as the PWM signal is at its falling edge, it will capture the required data. Easier said than done, the engineers toil hard to keep the timers in sync.

Challenge 2: One ADC, many roles! : In simpler microprocessors, the Analog to Digital Converter (ADC) is usually a software triggered one and hence, a simplistic version.

However, when a current filtering software is in place, this humble ADC has to switch jobs instantly and perform multiple functions.

For example, when the software must read the current, the ADC pauses its current job of analog to digital conversion and joins the software in reading the precise value of current.

After the job is done, it goes back to its usual job. This cycle continues at every instance of PWM triggering.

The timer that we discussed in the previous challenge decides when the ADC will come to aid the current filtering software and when it returns to the normal mode.

What do we conclude?

Reducing the hardware components from a motor control system is done to keep the cost under check.

This advantage is important enough for the product engineering service providers and suppliers to invest their time and effort on it.

Building such a software is a one-time investment compared to a hardware filter, where every component entails cost. Going by the recent developments and researches, engineers will be able to reduce more such hardware components from the motor control systems.

Definitely, a great news for automotive industry in general and Electric Vehicle industry in particular where a lot of success depends on motor controller solutions.


  • 0

Development of a Solar Panel Controller to Overcome the Shadowing Issue

 

About the Customer:

Our customer is a pioneer in the energy delivery systems and one of the largest clean energy companies globally.

They are one of the most trusted providers of energy from sources that include traditional and renewables (Clean Energy), Gas, and Steam.
 

Business Challenge:

Our customer had envisioned a digital transformation initiative for one of their existing Solar Power Plants.

As part of this digitization project, our customer aimed to integrate IoT Technology Stack in order to increase the efficiency of the energy harvesting capacity of their Solar Power Plant.

The objective of this initiative was to overcome the following challenges:

  • Customer was facing a major shadowing issue in which the shadows from adjacent solar panels were falling on each other and negatively impacting the solar energy harvest from each panel. Each solar panel was massive in size and hence, the shadow that was falling on adjacent panels was huge.
  • How to best leverage the IoT System (sensors, algorithms & feedback mechanisms) to control the movement of the solar panels in order to efficiently follow the trajectory of the Sun, throughout the day.

The customer had existing hardware solutions in order to address these challenges, but they were not cost-effective and efficient.

Instead, the customer wanted to adopt a software driven and more efficient solution. This made them initiate a search for a Product Engineering Services partner, with in-depth expertise in Embedded and IoT Software Stack.

 

Embitel’s Solution:

After in-depth understanding of our expertise and experience in development of IoT Powered Solar Tracking System; the customer decided to join hands with our IoT Software Development team.

The solution architecture that we proposed involved developing an add-on controller card, which can be easily integrated with the existing Solar Tracking System of our customer.

  • The solution architecture involved designing the add-on controller such that it served as an interface between the master controller and the IoT Gateway. The solution also included development of sensors to detect the shadow from the solar panels and make necessary corrections in the angle and position of the panel.
  • Our team also developed the embedded firmware drivers and application for the solution.

 

Embitel’s Impact:

The client was looking for a cost-effective solution (with optimized BOM), which can be easily integrated with their existing system. Leveraging our hardware and software expertise, we were successful in achieving the objectives of our customer.

The add-on controller and the modified Sun Positioning (SP) algorithm helped us to overcome the shadowing issue and improve the overall efficiency.

 

Tools & Technologies:

  • RS-485 Serial Communication Interface.
  • SP Algorithm.
  • Microcontroller: IC MCU 32Bit 2MB Flash.
  • Inclinometer: For angle and position.
  • Python for Application Development.
  • Eclipse for Microcontroller firmware development.

  • 0

Introducing Check C Framework: The Power-Packed Tool for Unit Testing of Automotive Software

Category : Embedded Blog

An automotive software, like any other piece of code is developed as separate modules or software units. Verification of these modules is one of the most crucial tasks, during the product development projects.

During Unit Testing, each software unit/module is tested individually. The efficacy of unit testing depends on the following two factors:

  • How accurately the test-cases have been designed?
  • How diligently are these test-cases executed?

Check C is a champion in both these aspects. Being a robust unit testing tool for C language, it provides an interface for designing the test cases as per the required coverages.

The Check C Framework also facilitates automatic execution of these test cases and generation of the unit test reports.

Although Check C is not a pure-play testing automation tool, but the developers and test engineers vouch for its efficiency and flexibility in accurate designing of the test-cases and their execution.

In our latest video, we introduce to you the Check C tool, its various features and value-adds.

—-Video is embedded here———

Check C Framework: Key Take Away from the Video

  • What is Check C Framework?
  • Step-by-Step Unit Testing Flowchart (using Check C Framework)?
  • Unit Testing Methods Supported by Check C

Check C is an indispensable tool for software developers who code in C Language. As automotive embedded software are mostly written in C, this tool serves as a go-to Unit Testing tool for automotive product development teams.

If you are a budding developer or test engineer, this video will be your doorway to the world of unit testing of automotive software.

If you like the video, do show some love by liking and sharing the video. We have more such videos on our channel and tons of them are going to be released soon. So, don’t forget to subscribe the channel!


  • 0

AUTOSAR Software for an Ambient Lighting ECU and Integration of UDS Protocol Stack

 

About the Customer:

Our customer is a Tier 1 Supplier of Lighting Technology and one of the largest retailers of the automotive parts.

The three  primary product lines of our customer include Concept Lighting, Engine Management Systems (EMS) & Electronic Control Units (ECU) for the automotive.

 

Business Challenge:

Our customer had embarked on the journey of developing a next-generation Automotive Ambient Lighting product for one of the OEMs’.

This product line required development of an Auxiliary Lighting Module (ALM) Control Unit (ECU).

To design and develop this ALM Control Unit (ECU), our customer was looking to partner with a Product Engineering Services provider who can offer the following expertise:

  • Production-grade, ready-to-deploy and Industry-proven UDS (ISO 14230) Protocol Stack
  • Expert team who can support with the customization and the integration of the UDS Protocol stack
  • Expertise in Application Layer development for the Auxiliary Lighting Module ECU
  • Expertise in AUTOSAR Architecture (AUTOSAR MCAL, RTE and BSW)
  • In-depth understanding and product development expertise w.r.t CAN and LIN Interfaces

After the initial workshop discussions with our Software Development teams and also witnessing the demo of our production-grade UDS Protocol Stack; the customer had no hesitation in partnering with Embitel for the design and development of software for the Auxiliary Lighting Module (ALM) ECU.

Our teams had all the necessary software development (AUTOSAR) and tool-chain related experience and expertise.

Also, since we have had a successful partnership with the same customer for a Hardware Reverse Engineering Services Project in the past, the customer has had a first-hand experience of Embitel’s passion for quality delivery.

 

Embitel’s Solution:

The Solution Architecture:

AUTOSAR Compliant Software development
  • Auxiliary Lighting Module or ALM is an Electronic Control Unit which is designed to control functions like the light color as well as the intensity, to turn ON/OFF the sequence of Auxiliary Lighting Units or ALUs’
  • There can be multiple ALUs connected to a single ALM, as depicted in this diagram.
  • Each ALU had been designed to control individual lamp assemblies of the ambient lighting system.
  • Each ALU was required to communicate with the main ALM ECU through the LIN communication protocol interface.

The Solution (AUTOSAR Compliant Application Layer, Hardware Platform Software, CAN/LIN Interfaces, UDS Protocol Stack):

  • Compliance with AUTOSAR Architecture was a key consideration for the customer because they wanted to develop a modular solution architecture . This ensured a lot of business value-add for the customer.
  • Our expertise in the Vector Davinci toolchain made sure that we developed a robust AUTOSAR complaint Application Layer.
  • Our team executed the Unit Testing of the software using Tessy environment
  • Validation testing was done through CAPL Scripting. It was completely automated so as to allow us to test the responsiveness of the ambient lighting.
  • Our expert team designed the Hardware Platform Software consisting of Base Software, Handlers, Low Level Drivers, and UDS based Flash Bootloader Software was reprogramming
  • Our one-time licensing fee model for the production-grade UDS Protocol (ISO 14230) Software Stack, ensured that the customer enjoyed the value-adds of access to the source-code and the IP rights.

 

Embitel’s Impact:

Having all required capabilities in one place in addition to having the Tessy environment ready and a strong CAPL Scripting team in-house, our team was able to deliver a quality solution to the.

We could utilize several of our reusable components (like UDS Protocol Stack, Low-Level Device Drivers) to reduce the overall time needed to complete the software development.

 

Tools and Technologies:

  • Davinci Developer and Configuration
  • Microcontroller: Renesas RH850
  • Compiler: GHS
  • Test Environment: Tessy
  • CAPL scripting

  • 0

How to Leverage Model Based Development for Delivering AUTOSAR Software Components

Category : Embedded Blog

The ‘coveted’ standardization in the development of automotive software has been greatly facilitated by AUTOSAR. This made the automotive industry to embrace AUTOSAR Architecture with open arms..

And rightly so!

AUTOSAR follows an open software architecture. This enables OEMs, Suppliers, Product Engineering Service Providers to collaborate on projects without worrying too much about the underlying hardware platform.

For instance, as per the AUTOSAR Architecture, a software component is implemented in the Application layer that has an interface with a standard Run Time Environment (RTE) and not directly with the ECU Hardware.

Such software components of the AUTOSAR Architecture (like RTE, BSW and MCAL) that are developed as plug and play modules, can be deployed across different projects.

In certain projects, the AUTOSAR development team may need to design an additional component called the Complex Device Drivers (CDD).

At times, there are certain non-AUTOSAR software components (components not compliant to AUTOSAR Architecture) that need to be added to the control unit.

Or, a few hardware components such as Real Time Clock, I/O Expander or H-Bridge are required to be interfaced with the ECU hardware.

In such scenarios, CDDs are developed for each of the software or hardware components so that they can communicate directly with the microcontroller ( by by-passing the RTE and BSW modules).

In this pursuit of standardization, the most dependable approach to software and CDD development is the Model Based Development paradigm.

While the AUTOSAR Authoring tools like Da Vinci Developer helps the automotive engineers to create software architecture, the MBD tools (SIMULINK) are deployed to model the behavior and interfaces defined in the architecture.

The most compelling reason for leveraging the Model Driven Development approach ( MBD), is its well-established workflow and availability of robust and industry-proven tools (MATLAB-SIMULINK).

Also, SIMULINK has a native support for AUTOSAR and there is no need for creating AUTOSAR-specific models separately. SIMULINK along with Embedded Coder tool also provides seamless support for development of an AUTOSAR compliant software.

Based on what you have read so far in this blog, you must have realized that Model Based Design and AUTOSAR go along very well.

But the ‘devil lies in the details’!

So, let’s dig a little deeper to understand the intricacies.

Understanding the Importance of Workflow in AUTOSAR Compliant Model Based Development

When AUTOSAR and Model Based Development work in tandem, there are several tools involved. And there is a lot of cross-functional flow of data as well.

Therefore, compatibility between these tools such as SIMULINK (MBD) and Da Vinci Developer (AUTOSAR Authoring tool) must be seamless.

As these development processes are iterative, compatibility between the tools is a must-have. Therefore, understanding the workflow becomes of great importance.

The diagram below will help you understand the flow better:
MBD for Autosar
 

As shown in the diagram, following is the flow of data:

  • Software Architecture is created in AUTOSAR authoring tool w.r.t software components that are required to be developed.
  • As per the AUTOSAR software architecture, the Software component description files are exported through AUTOSAR XML file format, called the
  • These files are imported to modelling tools. ( most popularly used modelling tool is the SIMULINK tool from MATHWORKS).
  • Functional behavior of the software component is modelled and tested in SIMULINK tool.
  • Finally, the tested model is used to create code using E-Coder (code generation tool)
  • Simultaneously with Production Code, updated Software Component Description files are generated. This is done to maintain consistency between the final artefacts, which are the software code (.C) and description files.
  • Both these files are now integrated with the target hardware platform

Decoding the Top-Down, Bottom-up and Round-Trip Workflows

Development teams have choice of Different workflows for modelling of AUTOSAR software components.

A workflow can be chosen based on several factors; however, it is the specific project’s requirements that will help you to take the final decision.

Whichever workflow one chooses, it involves importing the SWC description file (arxml) to SIMULINK and generating the model and the code.

Let’s start with the Top down approach!

The Top Down Workflow generally starts with Software Component description file. The Following Steps are executed:

  1. The Software Component architecture and interfaces are first defined in the AUTOSAR authoring tool viz Da Vinci Developer tool. Based on the architecture and interfaces, SWC description files (arxml format) are exported.
  2. Next, the description files are imported to SIMULINK in order to create a skeleton model with interfaces exactly similar to the ones created in the Da Vinci tool. Alternatively, the ARXML file can also be imported to update an existing AUTOSAR model.
  3. This skeleton model with all the integrated interfaces, forms the base for simulating the logic of the required application. Stateflow tool is used for this purpose.
  4. An additional step to maintain traceability is performed using Requirement management tools like IBM DOORS. In this step, the model is matched with the requirements specified for the project.
  5. Now, the simulations are run to check the design. Verifications are conducted using Test Cases; these test-cases are defined using Simulink Test tool. Additional verification is performed with Equivalence tests (SIL testing).
  6. Once, the verification is done, MISRA C compliant code is generated from this Model (using Embedded Coder tool).

The next workflow that is widely used in Model Based Development of AUTOSAR components is Bottom Up workflow. The only difference in Bottom-up approach is that the modelling process starts with SIMULINK and later followed by the AUTOSAR Authoring tool.

Steps Involved in Bottom-Up Workflow:

  1. AUTOSAR software component description from arxml files is imported into a new Simulink model.
  2. The model is evolved and configured (based on application logic) to make it ready for AUTOSAR code generation. Verifications and Equivalence tests are performed.
  3. E-Coder tool in SIMULINK environment is used to generate code. Alternatively, AUTOSAR component builder can also be used to create the AUTOSAR software component.
  4. The code is then exported as C code and XML Description, which in turn is imported to AUTOSAR Authoring tool (Da Vinci etc.) for configuration.

The core part of the Round-Trio workflow is quite similar to the top-down approach and bottom-up workflow. The only difference is the point where the development starts.

A Round-trip workflow is a combination of Top-down and Bottom Up approach. Here, the flow starts from the AUTOSAR authoring tool (AAT), goes through SIMULINK, E Coder etc. and comes back to AAT.

A Stepwise breakdown of Round-Trip Workflow:

  1. Previously specified AUTOSAR component with description file is imported to SIMULINK
  2. Model is developed based on this file, by configuring the AUTOSAR elements, mapping the SIMULINK model to AUTOSAR component and validating the configuration.
  3. C Code and newly generated description files are exported using the E Coder tool.
  4. SIL and PIL testing is performed to verify the generated code.
  5. The verified code and description file are now merged with other systems in AAT (Da Vinci developer tool etc.)
  6. If there is any change in the description file, it can be imported back to SIMULINK and the model can be updated accordingly.

Value Adds of Using Model Based Development for AUTOSAR Software Components and CDDs

Whatever be the workflow, there are proven benefits of deploying MBD approach to AUTOSAR software development. We have listed a few here:

  • Development time can be reduced to half as code is generated from the AUTOSAR model library of implementing any new or additional feature through software component or CDD, ensures great amount of flexibility for the developers.
  • Projects that involve integration of existing AUTOSAR components to a larger system becomes simple due to .arxml files. It reduces the time by up to 70%.
  • Due to continuous testing at every stage of development, 80% of the errors are identified at the design phase itself
  • Ensuring ISO 26262 standard compliance becomes easier, as MBD tools have the required provisions.

Best Practices for AUTOSAR Modelling Using SIMULINK

AUTOSAR modelling using tools like SIMULINK comes with certain set of challenges and hence, following the industry-recognized best practices is a must.

Let’s talk about some of these best practices :.

  • There should be a well-defined strategy and roadmap for migration of the existing SIMULINK models to the AUTOSAR This is to ensure that different teams working on the project use a uniform approach, common processes and tools.
  • The workflow should be decided at the onset and the teams should stick to one workflow whether it is top-down, bottom-up or round-trip. Using different workflows in a single project can create ambiguities and cause unnecessary iterations and re-work.
  • There is a lot of design data that changes hands during an AUTOSAR modelling project. Thus, the data management strategy is a crucial part of the process and should be defined properly.
  • Modelling Standard needs to be established for both AUTOSAR and SIMULINK so that the models can be re-used and scaled up in future. It is also one of the pre-requisites of the ISO 26262 standard compliance
  • ISO 26262 standard is almost a de facto standard in automotive industry and all your activities in AUTOSAR modelling projects should be aligned to it. Planning for functional safety from the very beginning is very important, as introducing it a later stage will only cause re-works.

Summary

Considering the several value-adds of using model-based development for AUTOSAR modelling, it is quite evident that they are a match made in heaven.

Even the MBD tools like SIMULINK are designed to natively support the AUTOSAR architecture. The flexibility of AUTOSAR architecture and robustness of the MBD paradigm are destined to become game-changers for software development in Automotive Industry.


  • 0

VLOG: A Beginner’s Guide to the Embedded RTOS Programming and Kernel Porting

Category : Embedded Blog

Fast & Real-time response, Efficient processing of the concurrent tasks, increased support for connectivity: These are some of the critical requirements that are demanded by new-age embedded system applications.

This is especially true for event-driven software applications such as Vehicle Telematics, Advanced Driver Assistance System, Body Control Module & Solar Tracking Platforms.

In such applications, the consequences of any delay in processing data and responding to an urgent event, can be detrimental!

What is an RTOS (Real Time Operating System) and Why it is Important?

Such time-critical embedded applications necessitate the support of an OS architecture that can:

  1. Support the applications to respond to a sudden event, within a defined time-stamp
  2. Execute multiple tasks as per pre-assigned priority
  3. Handle seamless sharing of computing resources among multiple tasks

The only embedded Operating System architecture that can guarantee all these functions is Embedded RTOS( Real Time Operating System).

Wikipedia defines a real-time operating system (RTOS) as “an operating system (OS) intended to serve real-time applications that process data as it comes in, typically without buffer delays.

While the General Purpose  OS (GPOS) such as Linux and Android are widely used for various development embedded applications, they are not designed to cater to the requirements of time-bound and event-driven applications.

On the other hand, as Wikipedia states, a real-time operating system (RTOS) is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

We also have a tech blog detailing “What Makes RTOS an Ideal Choice for the Next Generation Embedded Applications?”. Do have a look at it.

So, how does an RTOS add value to embedded system development eco-system? Why is an embedded RTOS preferred over general purpose OS when it comes to time-critical embedded applications?
Find answers to all these questions in this introductory video.

Watch the Video here:

( video to be embedded)

Hope you find the video helpful and engaging. Please don’t forget to like it and share it with your network.

We regularly add similar tech videos on our YouTube channel. To watch them as soon as they ae launched, please subscribe to our YouTube channel!


  • 0

Automotive Control Units (ECU) Solutions

Category : automotive-insights

 
Electronic Control Units (ECUs), within an automobile, have not only increased in number but also in software and hardware complexity.

Despite this growing complexity we have partnered with global OEMs’ and Suppliers; to help them ensure that the automotive ECU (Electronic Control Unit) software and hardware development process is:

  • Compliant with the stringent quality standards of the Automotive industry
  • Cost-effective
  • Delivered as per the automotive control unit (ECU) product development roadmap

 

[Video] How is Model Created in Model Based Development of Automotive ECU Applications

ECU software and hardware development services

Embedded-Platforms

Automotive ECU Hardware & Firmware Development

  • ISO26262 compliant h/w and s/w development
  • Board Support Package design and development
  • Device driver development
  • Communication stacks, middleware and application development
  • BLDC and non-BLDC motors, sensors and actuator integration
  •  

    Model Based Development

    AUTOSAR 4.0 compliant ECU software development

  • AUTOSAR RTE, BSW and COM stack configuration and integration
  • AUTOSAR MCAL development
  • Communication & I/O Drivers development
  • Tools expertise: Comasso, Vector , ECU Spectrum, KSAR AUTOSAR.
  • DaVinci Developer tool for architecture design.
  •  

    diagnostic

    Model-based development of Automotive ECU product

  • Matlab/Simulink and auto code generation (Target Link and RTW).
  • Verification and Validation Services
  • Unit, Integration and Functional testing services
  • Model in loop (MIL) testing
  • Hardware in Loop (HIL) testing
  •  

    AUTOSAR

    ISO 26262 Functional Safety consulting

  • Functional safety consulting services
  • ASIL A and D compliant automotive control units development
  • ISO 26262 mandated Safety Planning
  •  

    diagnostic

    In-Vehicle networking & diagnostics services

  • Unit testing (white box), integration testing, functional testing, MIL and HIL testing
  • Project experience in CAN, LIN, FlexRay, MOST .
  • Integration, configuration and customization of UDS, J1939, KWP2000, ISOBUS, OBD2
  • Integration of 3rd party automotive stacks
  •  

    Snow

    A Handbook on Electronic Control Unit Applications & Services: Learn about our expertise in MBD, AUTOSAR and ISO 26262 Compliant ECU software/hardware Development


     

    Meet Our Automotive Leaders

     

    ECU Software Development and Testing: Customer Success Stories

    1. Electronic Control Unit (ECU) software migration for a Germany based Tier-2 Supplier

      • Software architecture re-design for migration of automotive ECU from Siemens C167 micro-controller to Tricore platform
      • We partnered with our customer for ECU software migration of a diesel engine based Commercial Vehicle (CV)
      • Modeling and auto code generation for ECU software using ASCET SD (ETAS)
      • Implementation of truck specific functionalities – Engine brake, Power take-off, Cold start aid system, High Idle governing, Limp home features for critical sensor failures
      • Implementation of CAN communication network with other ECUs (electronic control units) as per SAE J1939 standards
      • Implementation of Vehicle diagnostics serviced over serial communication line as per EOBD standards
      • This automotive ECU project was supported by Offshore and onsite teams of expert embedded software developers along with dedicated automotive control units testing team
    2. Hardware in Loop (HIL) testing of Automotive Control Units (ECU)

      • Unit testing and Integration testing of Exhaust System Software, CAN, KWP2000 and UDS services for a Germany based Tier-II Supplier
      • Test automation strategy and test-case preparation for automotive ECU system (electronics control unit)
      • Vehicle simulator – Multitron Labcar from ETAS, Measurement and Calibration – INCA software
      • Calibration through CCP using ES690 from ETAS, Flashing through PROF/ JTAG debugger
      • Vector CANalyzer for simulation and testing of CAN nodes, Automation of CAN testing using CAPL programs
      • Our team worked on the in-house tool of the customer for diagnostic testing (KWP2000 over CAN) of the automotive control units system
    3. Mutation Testing of a Power Steering ECU for ISO 26262 (ASIL D) Compliance

      • Software architecture re-design for migration of automotive ECU from Siemens C167 micro-controller to Tricore platform
      • We partnered with a Germany-based Automotive Engineering Services company for verification and validation of an automotive control unit of Electronic Power Steering (EPS)
      • Mutation testing is a complex code structure-based automotive testing method. Such a verification & validation method requires skills in Advance C and automotive domain expertise
      • Designed automotive ECU software was required to be tested using Mutation Testing method in order to conform to the Automotive Safety Integrity Level (ASIL) D of the ISO 26262 standard
      • Our team analyzed EPS ECU software architecture to developed in-depth understanding of the embedded software code
      • Mutant Codes were designed for all the test-cases
      • Our Automotive Testing team partnered with the customer for technology workshops in order to get hands-on training with the proprietary tools
      • Test-cases were executed and mutant testing results were reported using the proprietary tools
      • We analyzed mutant test results to identify ‘acceptable’ and ‘not acceptable’ mutants (mutant codes that were not killed)
      • Our automotive software engineers reworked on test scripts to kill ‘not acceptable’ mutants

     

    FAQs for Electronic Control Unit Development Services

     

      Ans. In our 11+ years of automotive ECU software development journey, we have successfully delivered projects designed on some widely deployed microcontrollers:

      Here’s a detailed list of MCUs, based on which we have delivered several automotive projects:

      • TI Microchip NXP- Automotive Sun-roof System
      • Renesas NXP MC Platform– Motor Control Systems
      • ST Microelectronics– Automotive Sunroof System
      • NXP MPC Micro Series– Electronic Power Steering (EPS) ECU
      • Infineon – Battery Management System for Electric Vehicles, DC to DC Converter for Solar powered EV charger
      Ans. First, we can custom-develop the Board Support Package (BSP) packaged with the all the low-level drivers and APIs to facilitate the integration.

      If no customization is needed in the BSP software provided by the chip vendor, we can partner with you for the development of all the interfaces that may be required for the integration of application software.

      If you wish to migrate your application software to a new microcontroller platform, we can also provide BSP customization/development and driver development support for this.

      As part of the integration support, the following will also be the part of project deliverables

      • Enhanced APIs to help the application get the required data from base software modules
      • API documents, if the integration needs to be executed by your in-house team
      Ans. Yes, we will provide in-vehicle network compliance tests for CAN or LIN. This test is performed w.r.t to a protocol parameter in order to test the system under stress conditions.

      For instance, LIN will be communicated with 500 Kbps of data rate, a lot of signals will be passed simultaneously, and several error scenarios will be created in the testing tool. We will investigate the software and its behavior under such test conditions.

      CAN/LIN Project Reference: We have partnered with one of our US based customer for CAN and LIN compliance testing of an automotive roofing system.

      Based on the results of the test-case scenarios, our team was able to deliver a stable software solution. CAN/LIN compliance testing helped us to ensure that the software stack was tested to perform as expected, under all vehicle environments and operating conditions.

      Ans. Yes. We have partnered with many customers for integration of third-party stack, with the existing application software and MCAL drivers.

      If you have the third party stack and want us to develop a Bootloader based on the stack, our team has the required expertise to deliver the same.

      We can also develop the low-level drivers required to facilitate the integration

      These are the components that we offer as an integration service, following are the details:

      • MCAL development and integration
      • Communication Stack (UDS, Bootloader etc.) integration
      Ans. We provide development support for a range of automotive control units. Some of the automotive ECUs for which we have partnered with OEMs and suppliers are:

      • Body Control Module
      • Motor Controller- DC Motor, BLDC Motor, Induction Motor
      • Electric Vehicle ECUs – Battery Management System,
      • ECUs for Adaptive Lighting systems
      Ans. The following are the details of the control algorithm that we can develop for the motor control system. We can provide support for both open and closed loop control systems:

      • Field Oriented Control Algorithm: can be developed by manual coding or by Model Based Development (MBD) with MATLAB
      • Proportional Integral (PI) Algorithm
      • Proportional Integral Derivative Algorithm for closed-loop control system using MATLAB
      • Current Regulation Algorithm
      • Speed Control Regulation Algorithm
      • Soft Start/ Soft Stop Algorithm for controlled motor starting and stopping
      Ans. We are fully equipped to handle any 3rd party tool-specific unit testing requirements. The 3rd party tools, for which we have provided support to our partners, include RTRT, PolySpace, MxDev tool, QAC and more.
      Ans. The need for an interface for ECU re-programming and vehicle diagnostics is growing quite rapidly and we have the right set of skills and expertise to handle this.

      We can develop Human Machine Interface (HMI), configuration tools, mobile apps, PC utility tools to help our customers with ECU reprogramming and vehicle diagnostics applications.

      Project Reference: One of the configuration tools that we had developed for a customer, was to create codes for thousands of signals in a CAN DBC. Manually, it would take a minimum of 30-40 days for the task, but with our configuration tool was able to execute the same within few minutes.

      Ans. Yes, we will provide calibration protocol support. Both XCP and CCP based calibrations are supported along with UDS based vehicle diagnostics calibration.

    Related Blogs: Learn More About Automotive Control Unit Solutions

     

    Knowledge Bytes
      What is an Automotive Electronic Control Unit?
      An Electronic Control Unit is an embedded system tasked with controlling the vehicle’s electronic system. The heart of a vehicle may be all metal but its brains are the control unit that regulates all systems and processes.
      From basic components like engine and powertrain to the advance ones like anti-lock braking and seating control, an automotive ECU is the brain behind each of these systems.

      In-vehicle networks like CAN, FlexRay, MOST. help the ECUs in communicating with the relevant components.

      Some of the most common automotive ECUs are

      • Engine Control Unit
      • Transmission Control Unit
      • Body Control Module
      • Telematics Control Module.

    • 0

    What Makes RTOS an Ideal Choice for the Next Generation Embedded Applications?

    Category : Embedded Blog

    Over the past few decades, software and hardware solutions for   solar tracking & harvesting systems, battery management systems for enterprises and electric vehicles, Body Control Modules and Motor Control Solutions,  have witnessed a steady shift in complexity of the application layer.

    In this era of connected cars and Industry 4.0 automation, software and hardware solutions are expected to efficiently support features that are driven by real-time data.

    This requires context-switching, at the speed akin to the blink of an eye.

    For such applications, it is necessary to design software and hardware solutions that execute each functionality as a pre-defined task as per the assigned priority.

    In order to achieve these objectives, an advanced level of multithreading has become the need of the hour. And the only architecture that can deliver such performance within the strictest of time boundaries is a Real Time Operating System or popularly known as RTOS.

    Embedded Systems (like Solar Tracking Platforms, Body Control Modules, HVAC Systems, BMS in Electric Vehicles) have design  limitations in terms of power, system clock-time, and memory footprints.

    While General Purpose Operating Systems (GPOS) can handle multiple tasks efficiently, they usually do so without the pressure of time running out.

    RTOS on the other hand is designed to deliver an accurate output within the expected timeline (which as stated earlier, is akin to the time taken for the blink of an eye).

    In the rarest of instances of an RTOS delaying response, catastrophic events may occur. Hence, in an embedded system, an RTOS shoulders a highly critical responsibility.

    Let’s delve a little deeper and try to explore this time-critical operating system a bit more.

    Understanding the Basics of Real Time Operating System (RTOS)

    An embedded RTOS is a high-performance, cause-and-effect driven operating system that’s perfectly suited for real-time embedded system applications.

    RTOS is specifically required for applications which have time-critical requirements and need to respond instantly. It is used in systems where multiple operations are being executed at the same time and resources are being shared.

    Usually, an RTOS has small memory footprints and hence can easily be integrated into a microcontroller (MCU) platform.

    RTOS Porting

    Image 1: Architecture Diagram of a typical embedded RTOS based application

    At the core, it performs the basic function of redefining the software functionalities into multiple “parallel” programs known as “tasks.” It thus stands true to the concept of true multithreading.

    In the language of computer architecture, a Multithreading defines the ability of a processing unit to manage multiple threads concurrently. This approach helps in ensuring efficient

    sharing and utilization of the computing  resources by these concurrently executing threads.

    At its best, an embedded RTOS creates an illusion of parallel execution by rapidly switching between the executing tasks. It enables you to inculcate a new level of abstraction into applications which paves the way for more complexity to be built into them.

    It gives the product development teams complete control over multithreading, thus enabling deterministic real-time behavior.

    Traditionally, in case of complex applications, development teams relied on custom states and logic for successful execution of the control mechanism.

    However, as the complexity of electronic systems increased manifold, this became more error-prone and difficult to maintain.

    With RTOS programming, the execution of control is now delegated to a highly optimized RTOS Kernel.

    RTOS (Real Time Operating Systems ) v/s GPOS (General Purpose Operating Systems)

    All tasks within an embedded RTOS have specific timelines associated with them. However, tasks within a GPOS aren’t bound by a timing mechanism. Let’s try to understand the difference with an example.

    If you need to copy some data from one PC (Personal Computer)  to another, a GPOS may take several minutes to do so. It might complete the procedure without glitches or may even hang during it since several tasks are being executed in parallel.

    An embedded RTOS doesn’t enjoy this kind of liberty. Tasks must be completed within the strict deadlines and in parallel, in order for the system to honor the SLA.

    For example, in an automatic air-bag control system, as soon as the vehicle senses a sharp jerk, the air-bags should be activated without the delay of even a second. This is because even a milli-second of delay can lead to a serious injury for the driver.

    RTOS vs GPOS
    Image 2: RTOS vs GPOS: Comparison chart; Source: ami.com

    Evaluating and Selecting an RTOS for an Embedded Product Development

    While evaluating an embedded RTOS that can perfectly fulfill the business and technology requirements of an embedded application, your team should ensure that the RTOS in considerations supports a set of critical features.

    Let us have a quick look at these features:

    • Schedulers – Operating system schedulers are responsible for deciding which task should be executed at which time. They can suspend any task and resume it later, depending on availability of resources and priority. An embedded RTOS should have a scheduler built into it, which will enable it to perform real-time execution of the tasks.
    • Software Timers – A software timer allows a function to be executed within a set time-window. Manually creating software timers within an RTOS can become very complex and error-prone . Hence, it is always advisable to select an RTOS with in-built software timer functionality.
    • Queuing Mechanism – Queues are software mechanisms for exchanging information between tasks. In other words, queues facilitate smooth inter-task communication, or between tasks and interrupts. With queues built into an RTOS, different tasks will be able to exchange messages with each other
    • Execution Trace Tools – To fully understand the runtime behavior of an RTOS based system, you need the ability to observe its real-time behavior at the RTOS level. This can be achieved with the help of a tracing tool. If an RTOS has execution trace tools built into it, development teams can track the execution of tasks and detect discrepancies if any.
    • Low Memory Footprint – Since an RTOS needs to be integrated into a MCU platform, it should have a very low memory footprint. That is to say that its total size should not be in excess of 10 percent of the total size of the MCU.

      In addition to having the above-mentioned features, an embedded RTOS should be compatible with the target MCU architecture.

    How to Port an RTOS Kernel to a Target MCU Platform

    Once you’ve selected an ideal embedded RTOS for your desired embedded system, the next phase involves accurately porting an RTOS kernel into the target MCU platform.

    The procedure involves several steps that should be carried out with care in order to make the system function smoothly. Let us look at the key steps involved in the successful embedded RTOS kernel porting onto target MCU architecture.

    1. Checking whether the RTOS is compatible with the MCU

      As a developer, one must ascertain if the selected RTOS is compatible with your target MCU. This step often involves interfacing the required interrupts to the right ports and conducting rigorous integration tests to verify that everything is working together perfectly.

      If any missing links are found, you might need to either switch to a different RTOS kernel or use some kind of middleware to ensure compatibility.

    2. Ensuring that the IDE supports the features of RTOS

      In order to develop embedded systems with optimal performance, developers need comprehensive Integrated Development Environment (IDE) and a compatible RTOS. But selecting the two is only a part of the process. They need to make sure that both the IDE and RTOS are compatible with each other. In addition to selecting an RTOS, you need to choose an IDE which supports the features included in the particular embedded RTOS.

    3. Configuring the RTOS Kernel image based on the target microcontroller specifications

      If the selected RTOS is compatible with the target MCU and the chosen IDE, the RTOS kernel must next be configured according to the MCU’s specifications. This will ensure that once the system starts working, data and information exchange happens without glitches.

    4. Device Driver Development

      Once all compatibility checks and required configurations have been done, the appropriate device drivers need to be developed for the target system.

    5. Connecting the BSP layer with the RTOS layer

      BSP or Board Support Package is a layer of software containing hardware specific drivers and routines which allows an RTOS kernel to access the resources of the  specific hardware system. After driver development, one needs to interface the BSP layer with the RTOS kernel layer.

    6. End-to-end application development

      Now that all the conditions and  pre-requisites for building a fully-functional embedded system with RTOS as the core is met. The next step is development of full-fledged embedded application.

    7. Debugging the application

      And finally, once the embedded application development is complete, you can progress to debugging the application using set of debugging tools.

      For a detailed monitoring of the run-time behavior and performance of the RTOS based embedded system, as mentioned in the above section, developers prefer execution tracing tools during debugging. These tracing tools help in recording detailed execution events within the RTOS kernel and quick identification of any bugs/anomalies therein.

    A Few Final Thoughts

    As the market expectations for real-time responsiveness from modern embedded systems show a steep increase , usage of an RTOS as become more than a necessity than a desirable option.

    In addition to real-time responsiveness, an RTOS powers such embedded systems with several advantages like low-memory footprint, deterministic task handling, optimal resource usage, and extensive multithreading capabilities.

    In the era of connected systems brought in with the evolution of Internet of things that demand on-time response clubbed with optimal resource utilization, it won’t be wrong to say that the RTOS based systems are here to say!