×

Happy to Help!

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

Great, thanks!

Functional Testing of Climate Control & Heated Seat ECUs

  • Home
  • _e("Posts tagged","weblizar") "Automotive ECU"
  • June 28, 2018
  • 0

Functional Testing of Climate Control & Heated Seat ECUs

Tags :

Category : Automotive control units-design and development , Product Engineering

 

About the client:
A US based Tier-1 supplier of thermal and climate control systems for various industries like automotive , healthcare, logistics, and more.

 

Business Challenges:

Our customer is a trusted name in the automotive Industry for their climate control and heating/cooling solutions for the Seat ECU.

In order to uphold this legacy even through their existing and future automotive ECU products, our customer wanted to ensure that their Climate Control seat ECU solutions are tested with 100% coverage of the test-cases.

Hence, this reputed Tier-I automotive supplier was looking for a trusted Functional Testing partner with extensive experience in the Automotive Industry and expertise in the HVAC systems.

Heated Seat ECUs
Image: Cooling & heated car seats

 

Embitel Solution:

After the initial phase of discussions, our automotive testing team spent sufficient time to understand the customer’s product line as well as the development process.

We also shared some of our Global Success Stories with the customer. Having gained trust and confidence in our ‘People, Process and Technology’, this partnership of mutual success was inked!

Post the kick-off of this challenging Functional Testing project, our Automotive Testing team collaborated with the US based Automotive Supplier for the following work-products:

  • Functional Testing of different Heat and Vent Modes of the Automotive Seat ECU (electronic control unit)
  • Functional Testing of Remote start functionality
  • Functional Testing of all possible faults such as Short/Open to battery, Short/Open to ground.
  • Functional Testing of Diagnostic Trouble Codes based on different instances of faults such as a malfunctioning of Heater or Cool element, Voltage and current abnormalities and more

Our Automotive Testing Team attributes the success of this project to the creation of a well-defined workflow along with the project management (DOORS by IBM), quality management (Quality Manager) and simulation tools (CANalyzer / CANoe) that were deployed for this project

The following Testing Process Diagram gives a complete overview of this robust Functional Testing ecosystem designed by our Automotive Software team:

functional testing

  1. Requirement Specification: The client uploads the requirement and functional specification on the DOORS (Dynamic Object Oriented Requirements Management System).

  2. Artifact Analysis: Embitel’ s automotive testing team analyzes each of the artifacts uploaded in DOORS to segregate the software requirements from the hardware requirements.

  3. Test Case Definition: The team then defines specific test cases corresponding to each software requirement, in the Quality Manager Tool.

  4. Linking Test-Case: Next, each of the test-cases is linked to achieve bi-directional traceability.

  5. Software Simulation: Once the test cases are defined and linked, Simulation Software is developed for DUT (device under test) using either CANalyzer or CANoe.

  6. Testing: Next the automotive testing team executes the Test Cases.

  7. Bug Identification & Logging: All the bugs detected during the testing are logged into the Quality Manager and a test summary report is created for future use.

  8. Bug resolution: The bugs that were logged in the Quality Manager are appropriately tracked for resolution.

  9. Reporting: If the number of bugs reported is found to be more than a prescribed number, software requirement is shared with the customer for further inspection.

  10. The complete testing procedure, right from step 1, is repeated if the number of bugs reported is high and further testing is suggested by the client.

 

The Embitel Impact:

  • Embitel ensured that the product development was validated with 100% functional testing coverage during the process. This ensured that the Climate Control seat ECU was validated for all the software artifacts and any failure to meet the project requirement has been adequately reported.
  • Embitel team’s had an in-depth understanding of functional testing of automotive systems. It helped in accelerating the test-case development, execution and identification of the critical bugs, much before the product release.

 

Tools & Technology:

  • IBM Jazz: is an extensible technology platform that is used to integrate tasks throughout the software development lifecycle.

  • Rational DOORS (Dynamic Object Oriented Requirements Management System): is a requirement management applications built on Object Oriented Database. The tool has an open architecture that supports third-party plugins.

  • Rational Quality Manager: IBM’s rational Quality Manager is web-based, quality management solution that helps in seamless test planning and test asset management. The test management tool, built on Jazz, offers a central repository of test data and the tests are organized into test plans.

  • Vector CANalyzer: is a comprehensive analysis software tool used by automotive companies to analyze the data traffic in serial bus systems like CAN, LIN, FlexRay, Ethernet, J1939, MOST etc. It is developed by Vector Informatik GmbH.

  • Vector CANoe: is software a development and testing tool , developed by Vector Informatik GmbH. Used mainly by the automotive manufacturers and suppliers, Vector CANoe, supports a wide range of vehicle bus systems. It is widely applied for development, analysis, simulation, testing, diagnostics and start-up of automotive ECUs.

  • Tool chain: The climate control ECU is based on PIC (or) Renesas based Microcontrollers tool chain.
  • September 28, 2017
  • 0

An End-to-End Actuator Design Solution for a Throttle Control Unit (ECU)

Tags :

Category : Automotive control units-design and development , Product Engineering

 
Customer:

A U.S. based Automotive Supplier with presence in more than 35 countries. They are a reputed name in ADAS, suspension, transmission automation, braking and stability control systems for commercial and off-highway vehicles.

 

Business Challenge:

  • Our customer had identified an Automotive ECU (from their existing product lines), that was best suited for the Throttle Control Application.

  • Next step was to develop an Actuator to complete the closed-loop system for Throttle Control.

  • After a detailed feasibility study, customer’s in-house R&D team realized that it was imperative to partner with an expert automotive embedded engineering partner, for this actuator development project.

  • The following were the most critical reasons for outsourcing this actuator software and hardware development project:
    • Customer realized that this project had some inherent challenges. Since this actuator was to be deployed as part of the powertrain system (near the engine area). The actuator design & components were required to sustain harsh operating conditions (temperatures up to 200 0C, high levels of noise and pressure) and perform optimally.
    • Commissioning this challenging actuator development project in-house, meant increase in time-to-market and overall project cost.

 

Embitel Solution:

  • With the Value Engineering approach, our embedded system development team was able to successfully deliver the ECU actuator by overcoming the challenges of difficult operating conditions.

  • Our expert team leveraged their automotive domain know-how and the expertise in recognizing and sourcing the best suited automotive grade components. We also implemented some critical design best practices to make sure that the ECU actuator performs optimally under all operating conditions.

  • E.g. – Our team designed enclosures protected by closing thermal channels in order to make Capacitor, with Dielectric X8R, perform optimally under operating temperatures of up to 200 0C

  • Following is the step-by-step snapshot of this ECU Actuator development project:
    • Thermal and Electromagnetic Analysis and Simulation of the operating conditions using HyperLynx, FloTHERM and PSpice.
    • Schematic system design using OrCAD.
    • Building the ECU Actuator Prototype using Allegro (for layout design)
    • Functional testing of the Actuator Prototype using proprietary tool of the customer.
    • Prototype testing – Endurance Testing, Burn-In Testing and Performance Testing.
    • Support for issue resolution or bug-fixing post testing.
    • Support for End-of-Line testing, pre-compliance and post-production maintenance.

 
Block Diagram: Actuator & External ECU Architecture

Wabco Case-study-Actuator-ECU Development -Bangalore-India-Embitel

 
Embitel Impact:

  • Successfully resolved the design challenges related to harsh operating conditions and delivered a cost-effective solution.

  • Our expert team helped customer choose right tools for PCB and system layout design. This ensured that we deliver a stable and reliable actuator solution.

  • Reduced time-to-market and overall project cost.

 

Tools and Technologies:

  • OrCAD for Schematic design

  • HyperLynx for thermal and Electromagnetic analysis

  • FloTHERM for Computational Fluid Dynamics analysis

  • PSpice for Simulation
  • August 7, 2017
  • 0

How to Integrate J1939 Software Stack With an Automotive ECU: A Step-by-Step Tutorial

Tags :

Category : Embedded Blog

If you are an embedded software engineer (or an enthusiast) ready to kick start your career in the exciting automotive ECU development space; this tutorial can serve as a high-level hands-on of J1939 stack integration with automotive ECU and/or tooling applications

Why J1939 stack integration in automotive ECU applications:

Before we start with our J1939 tutorial and address the step-by-step process involved behind the J1939 software stack integration, let us first look at the significance of J1939 integration.

  • J1939 software stack is compliant with SAE J1939 standard.
  • This software standard, defined by Society of Automotive Engineers (SAE), has been designed to ensure that Electronic Control Units (ECU) (manufactured by different automotive suppliers) follow a standard format to communicate with each other.
  • This standardization ensures interoperability between control units from different suppliers along with other benefits
  • J1939 software stack, in particular, supports communication and diagnostics services over CAN bus for commercial vehicle applications

 

Decoding J1939 software stack integration process:

In the system architecture diagram shown below, we observe that:

  • The J1939 stack is the middleware (middle layer) software
  • J1939 software stack is integrated between the Low Level Device Drivers (LLDs’) and automotive application.
  • In addition to this, there is also a J1939 based Bootloader software (part of the J1939 stack) and a Scheduler software, that are part of the ECU software architecture

J1939 based Bootloader software
 

Following are the steps involved in J1939 software stack integration:

Step 1: Development of APIs’ (and device drivers) for integration with target platform and application layer:

  • The Low-Level Device Driver layer consists of all the device driver software code that facilitate access to the underlying hardware platform (MCU, I/O ports, Timer) and other integrated peripherals
  • To enable communication of this Low-Level Device Driver layer with the Middleware Software (aka J1939 stack), an API software is designed
  • Such an API is designed to leverage following advantages:
    • The customer (an Automotive OEM/Supplier/Tooling vendor) may choose to provide only limited or no access of the low-level device drivers to the third party J1939 stack vendor. (Reason: This helps to safe-guard the mission critical data and architecture.)

      • In such scenarios, the software services vendor develops this API (as part of the J1939 package) which can be integrated with the low-level layer by the customer’s in-house software development team.

    • Since low-level device driver programming is more complicated, the higher level interface, facilitated by an API, makes configuration, customization and/or modification much simpler for the software developers
  • An API is also designed to enable integration with the target application layer of the ECU/Tooling system

 

Step 2: Configuration of the Middleware layer (J1939 stack)

  • There are several off-the-shelf J1939 software solutions available in the market.
  • Automotive companies, over the years, have shown confidence in such pre-tested stack solutions. Such ready-to-deploy J1939 stacks add value by saving development time and cost
  • However, to integrate this stack solution, the vendor provides support for the configuration of Application (J1939 – 71) and Diagnostics (J1939 – 73) layers
  • The level of configuration and customization required, depends on the business needs of the end-user application
  • Configuration of J1939/71 Layer: This layer is configured to define Parameter Group Numbers (PGNs), Suspect Parameter Numbers (SPNs) with the Scaling, Limits and Parameter Offset Size.
  • Configuration of J1939/73 Layer: This layer is configured to define Diagnostic Trouble Codes (DTC), Diagnostic Parameter Group Definitions and Diagnostic Messages (DM)

 

Pro-tip: This blog tells you how to test the quality of J1939 source code before integrating it with your ECU application.
 

Step 3: Compilation and Porting of the code on Target Hardware Platform

The general steps for compilation of source code into an executable file, are as follows:

  • Pre-processing: In this step the source code file is processed and transformed for compilation.

    • For an instance, if the code is written in C or C++ then the source code file will be in .c or .cpp format. The output of the pre-processing stage is .i or .ii file format.

  • Compilation: The output of the compilation stage is a file containing assembly language code to be interpreted by the assembler.
  • Assemble: In this stage the input file of assembly language code is converted into machine language file.
  • Linking: The linking phase of compilation process is responsible for producing an executable file.

To summarise, using an Integrated Development Environment (IDE),the source code is converted into an executable format. The compiled output files which are in .hex and .s19 format can be ported directly on the target Hardware platform.
 
Other optional steps involved for the integration of J1939 software stack:

  • J1939 Bootloader software development:

    • The Bootloader software is required for re-programming of the Automotive ECU. The bootloader functionality is a part of the J1939 software stack.

    Depending on the automotive application requirements, the J1939 bootloader sequence can be configured.

    Also, the bootloader logic is implemented separately for both boot and application areas.

  • Scheduler software development for non-RTOS systems:

    • In simple terms, a scheduler helps the embedded system to multitask in an organized way.

    Scheduling of tasks is imperative, due to increasing complexity of functionality in the layered system architecture.

    The scheduler software can be configured in two ways:

    • Based on the required time constraints set upon each tasks
    • Based on the number of tasks that have to be configured within a particular timestamp.

 

Challenges you may face during integration of J1939 Software Stack:

As you may have realized, integration of J1939 stack involves ensuring compatibility between three layers: Low-Level Device Drivers, J1939 stack layer and the Application Layer

The challenges during such a J1939 integration project are encountered due to faults at or limited access to the device drivers layer and/or application layer of the customer devices

If your J1939 stack source code is robust, pre-tested and has been proven by integrations across different platforms for different projects, then it is unlikely that you will face challenges due to faults or errors in the middleware software layer

Following are some suggestions to resolve a road-block during a J1939 software integration project:

  • When a specific software module in the LLD is faulty:

    • Fault may occur during J1939 software stack integration with the LLD layer, due to reason such as improper functioning of CAN module.

    In such a scenario, the error can be handled by carrying out the RCA (Root cause analysis).

    In cases where the customer shares limited access or no access to the LLD layer, the concerned teams from both the customer and vendor’s organization need to collaborate to resolve the issue.

  • When the application layer sequence is faulty:

    • The end user application can create a hurdle if it does not function properly.

    For example,if a data identifier does not have a proper sequence or format then, the particular diagnostic instruction will not be interpreted accurately by the ECU.

    If the application is developed by the customer, it is recommended to share the legacy library with the team responsible for integration of J1939 stack.

    This legacy library has details of the interface requirement of the application. This knowledge can help a software development team to resolve critical issues.

For more details or queries regarding integration of J1939 solution, please get in touch with our experienced team of automotive software developers

  • February 21, 2017
  • 0

Mutation Testing of an Automotive EPS for ISO 26262 (ASIL D) Compliance

Tags :

Category : Automotive control units-design and development , Product Engineering

 

Customer:

An European Automotive Engineering Company, specializing in Powertrain and Body Electronics Development

 

Business Challenge:

Our customer was in search of a trusted Automotive Embedded technology partner with specialized skills in Mutation Testing of the automotive EPS ECU (Electronic Control Unit).

In order to conform to the Automotive Safety Integrity Level (ASIL) D of the ISO 26262 standard, it is mandatory to test the designed automotive ECU software using Mutation Testing method.

Mutation testing is a code structure-based testing method. In this method the original embedded software code is altered to create mutant code.

  • Mutant code is designed to fail for a specific test-case created by QA or testing team. If the original code gives satisfactory output for a test-case and mutant code fails for the same test-case then the mutant is pronounced dead.

  • If the mutant code doesn’t fail for a specific test-case, then the test-case is modified and tested for same mutant to ensure that the mutant is dead..
mutation testing

Such a complex automotive software testing procedure can only be performed by a highly-skilled team with in-depth expertise in Advance C and domain expertise of the Automotive Embedded Systems and Control Units.

Our customer also had an urgent need as the project completion timelines were very stringent and ISO 26262 functional safety certification of ASIL D level had to be achieved before the launch of the automotive EPS in the market.

 

Embitel Solution:

Our Automotive Software Development team not only had the required skills in Advance C coding but we also added value with 10+ years of automotive domain experience.

  • We analyzed the entire EPS ECU software architecture and developed in-depth understanding of the complete structure of the software code
  • Our automotive domain experts worked with our QA and Testing teams to identify use-cases and design different test-cases with 100% coverage for all scenarios
  • Our software testing and QA team designed Mutant Codes for all the test-cases
  • The QA and Testing teams partnered with the customer for technology workshops in order to understand and get hands-on training with the proprietary tools
  • All the test-cases were executed and mutant testing results were reported using the proprietary tools of our customer
  • Our automotive ECU software testers analyzed mutant test results to identify ‘acceptable’ and ‘not acceptable’ mutants (mutant codes that were not killed)
  • Our automotive engineers reworked on test scripts to kill ‘not acceptable’ mutants

 

Tools and Technologies:

  • Advanced C skills
  • Mutation Testing method
  • Microsoft Visual Studio
  • Proprietary Tools belonging to the customer.

 

Archives

Contact Us

© 2018 Embitel. All Rights Reserved