×

Happy to Help!

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

Great, thanks!

Check C framework for Automotive Applications: A Powerful Unit Testing Tool that’s Smart & Flexible

  • 0

Check C framework for Automotive Applications: A Powerful Unit Testing Tool that’s Smart & Flexible

A lot rides on the electric control units ECUs and the software that sits inside it. From the manufacturer’s reputation to the safety of the vehicle occupants, embedded software is powerful enough to leave an impact on these critical factors.

Hence, there is no scope for errors and bugs when you are developing automotive embedded software for critical vehicle ECUs.

So, as an automotive software developer, what should one do to ensure that the automotive ECU software is foolproof? Software Testing is your friend in need!

As the automotive software are quite complex with each module having several functionalities, the software testing process also gets quite tricky and time consuming.

Tools like Check C come to the rescue of the automotive software developers and the testing engineers like you, to ensure that you deliver quality products.

In this blog, we will talk about the capabilities of Check C tool and how this tool makes the unit testing process a little easier for the automotive software development team.

Overview of Check C, a Unit Testing Tool

Essentially, Check C is a software tool for writing and executing unit tests. However, there is more to what meets the eyes.

Check C is an open source tool and this is one of the reasons why it so popular among the embedded software engineers. Ask any seasoned embedded software developer and they will tell you how special the tool is.”

It may not be an automated unit testing tool, but it can enable automatic execution for the unit testing processes. The fact that Check C is standardized also makes it a reliable tool for automotive ECU testing.

The Prowess of Check C as a Unit Testing Framework

Simplicity is a vital aspect of the frameworks that need to handle complex codes. Check C is a winner in those terms. It boasts a very simple framework for the testing team to define the test cases.

There is a separate address space where the tests are run. This leads to the detection of both code errors and assertion failure that may cause segmentation faults.

Also, Check C supports test reporting in following formats:

  • XML
  • Tap
  • Subunit
  • And a generic logging format.

Of these formats, XML has been the format of choice across the software testing community.

Features of Check C testing tool:

  • Modifiable Code and Manual Scripting:

    For performing Unit Testing, as per statement coverage and branch coverage, the software testing team is required to write the scripts and codes manually.

    Of course, Check C framework verifies the codes and scripts, but gives the developers the flexibility to write the test cases according to their understanding.

    For instance, the code to generate the test report can be customized to support desired test report formats.

    Let’s say one needs to add the hyperlink to the test reports. So that, in case of the failure of any test cases, the developer can simply click on the hyperlink and C file will open. This is possible to implement using Check C framework.

    Also test reports that are generated as text files can be converted to XML files by writing simple scripts.

    Manual Scripting also offers some advantages, for example, in case of code changes, the script used previously will not give 100% test coverage. This makes it easy to identify any issue with the new code.

  • Check C APIs:

    Check C provides APIs for unit testing. Some of these APIs are Start Case-End Case, ck_assert_int_eq and more.

    Here is a code snippet that clearly depicts how one of the Check C APIs, Start_Test, End_Test work

    Check C APIs

    Each test case starts with START_TEST and ends with END_TEST. Similarly, other APIs have their functions clearly defined.

  • The Unit Testing Methods supported by Check C Tool

    Statement Coverage: This method is also known as Line Coverage because in this method, the tool checks every executable line of the code once. The objective of statement coverage is to identify ‘dead codes’!

    These are basically software codes that may have been written by the developer by assuming that certain condition will be fulfilled. However, during the execution of the entire function, such assumed condition is never satisfied and a specific set of code never gets executed (hence the name ‘dead code’).

    Branch Coverage: It is a little in-depth unit testing method, in which ‘if..else’ branches are tested. It can happen that a developer misses to include the ‘else’ condition in the branch causing output anomalies.

    Such errors can be easily identified by the branch coverage method. Branch coverage ensures that the branch is tested for both ‘true’ and ‘false’ scenarios. It helps in the validation of all the branches and mitigates any abnormal code behavior.

    Calls Executed: This part validates internal functions or API calls within the code. It checks whether the right function is being called and also whether the function is giving the desired output.

    Check C lets the software testing team input the parameters for API calls and validate the feedback/output based on those parameters.

    Modified Condition/Decision Coverage (MCDC):Ideally, every piece of code should have an entry point and an exit point. However, any instance of multiple entry/exit points need to be identified and reported. Check C does this efficiently with MCDC.

    Instances of misplaced break statement, pressing of ESC character and more will always lead to partially executed loops (certainly not desired and recommended).

    Also, there may be a scenario when two or more conditions (say A & B) need to be met for a particular test case to be 100%. Statement and branch coverage will not suffice here as they check only one condition. If the first condition is true, it will not execute further.

    These issues are identified by Check C using the modified condition/ decision coverage. To label a software code as “Tested Ok” for deployment in the production server, the percentage of statement, branch and calls executed is usually set at 100% and for MCDC, it is kept around 90%. This percentage can be specific to the projects and the safety criticality of the software component.

    At times, even after running all the test cases, MCDC may be at 70-80%. Check C provides a Dot GCOV file that can help the developer understand which part of the code did not execute.

    Shown below is a sample Unit test report and MC/DC code coverage report. The coverage percent along with other relevant info is mentioned

    Check C 3_MCDC_Embitel
     

    For Example: #### for the line/branch not executed

    Taken 0- for MCDC coverage failure

    Call 0- for call not executed

    Features That Make Check C the Preferred Tool for Unit Testing

    There are plenty of reasons why Check C is one of the most widely used open source unit testing framework. Following are the most striking features of Check C:

    • A lightweight tool that uses same language and development environment as the developer
    • Easy, systematic and a comprehensive method of organizing and executing the test cases
    • Check C Framework code can be modified according to specific testing needs
    • Reusable test functionality
    • Customized test report generation
    • Debugging the code using Dot GCOV file.
    • Automated regression testing

    These features bring along with them a host of advantages. We have enumerated some benefits of using Check C:

    The Benefits of Check C as a Unit Testing Framework

    • Code Robustness is ensured
    • Run-time error can be avoided
    • Open source nature reduces cost of development
    • Modifiable code for flexibility
    • Powerful tool as it simulates all test conditions
    • Boundary value checking
    • Dead code removal through various test coverage
    • Functionality can be validated efficiently

    Migration of Check C from Linux to Windows

    Check C is originally written for Linux. However, it can be migrated to Windows and other operating systems too.

    Migration to Windows OS is performed using Cygwin Software. It can be easily installed using the setup file freely available online on Cygwin website.

    The image shows the commands needed to run to get this migration started

    Check C 4

     

    After the installation, you need to download the Check C source code which is open source and available on https://sourceforge.net/projects/check/files/latest/download.

    A few commands on the Cygwin Terminal and you are good to go. A detailed tutorial for migration of Check C to Windows OS can be found online.

    Final Thoughts

    Check C as a unit testing framework does not attempt to be an automated unit testing tool. In fact, it aids the developer in executing the test cases in an ideal environment.

    It allows the developer to add manual scripting and do the desired code modification. With a semi-automated flavor to the framework, it is just what the developers coding in C language require- power with flexibility!


    • -

    Library of Vehicle Diagnostics and Communication Software Stacks

     

    Transformation of Engine Control Unit (ECU) into Electronic Control Unit (ECU)

    The Electronic/Electrical (E/E) systems within automotive now have more than 10 million lines of software code!

    As an embedded technology partner for our global automotive customers, we have witnessed this transformation over the past 10 years

    For such complex E/E systems robust network communications and diagnostic software protocols are critical for tracking and controlling of vehicle parameters.

    .

    Library of ECU communication and diagnostics stacks

    In compliance with Automotive and International Standards (SAE and ISO), we have designed and developed a suite of pre-tested and pre-packaged vehicle network communication and diagnostics protocols

    All the stacks can be readily integrated with any Automotive ECU and tooling applications

     

    Automotive Strack Library

     

    J1939 stack

    J1939 Stack
    The SAE J1939 complaint software stack and boot loader has ensured reduction in software development costs and time for our global customers.

    Following are some success stories of J1939 stack integration

    • Android based Infotainment platform – J1939 stack helps the IVI platform to fetch vehicle parameters and diagnostics information. The stack is integrated with Linux/Android operating system, and around 50 PGNs are configured.

    Read the complete success story here

    • Electronic Power Steering (EPS) system – The complete stack is integrated with EPS system for supporting vehicle communication, reprogramming, diagnostics and fault code memory.

    Read the complete success story here

    Learn more about the J1939 stack integration services

    J1939 software stack Factsheet:

    J1939 Stack PDF

    Our J1939 solution for commercial and light passenger vehicles has been deployed in several production programs, across the US, Europe and India.

    Download this J1939 Factsheet PDF to know more about this solution

    What this factsheet offers:

    • Details about J1939 licensing model and business engagement model
    • How our customers benefit by owning J1939 IP rights and access to J1939 source code
    • What are the J1939 software features, OS compatibility, memory requirements
    • J1939 stack integration, testing and maintenance services (pre and post production) offered by our Automotive Software Development team, based out of Bangalore, India

     

    UDS Stack

    UDS module, designed as per ISO 14229 standard, implements diagnostic services which allow a diagnostic tester (client) to control functions in an ECU (server).

    UDS implementation is independent of physical layer and it is compatible over both LIN and CAN implementation

    Embitel has ready-to-integrate solutions to support UDS based diagnostic implementation for control units and boot loaders based on UDS and tooling solutions for end of line reprogramming, service station diagnostics and remote diagnostics

    Following are some success stories of UDS stack integration

    • Diagnostics and reprogramming stack for body control unit
    • UDS over LIN diagnostics stack and reprogramming for roof control systems
    • Cloud based remote diagnostics
    • UDS based diagnostic tester – Customer Success Story

     KWP2000 Stack

    KWP2000 stack, designed as per ISO 14230 standard, implements diagnostic services that allow a diagnostic tester (client) to control functions in an automotive ECU (server).

    Our Automotive team has designed software stacks for KWP2000 over K-Line and KWP2000 over CAN (based on ISO 15765)

    We have ready-to-deploy solutions to support KWP2000 based diagnostic implementation for control units and bootloaders (over K-Line and CAN)

    Following are some success stories of KWP2000 stack integration

    • Diagnostics and reprogramming stack for Engine Control Unit (ECU)
    • End of line reprogramming over K-Line

    OBD/OBD II Stack

    Designed and developed in compliance with ISO-15031, the OBD II stack is independent of platform and application.

    It is portable to several Microcontroller families (8, 16 and 32 Bit Microcontrollers)

    Learn more about our OBD II stack integration services

    We support OBD stack on the following Network Protocols:

    • OBD over CAN (ISO15765)
    • OBD Over Kline ( Using KWP2000 Protocol)
    • OBD Over J1850 ( PWM and VPW)
    • OBD over ISO 9141-2

    OBD Stack

    Following are some success stories of OBD stack integration

    • OBD II stack and Fault Code Memory implementation for Engine control unit – customer success story
    • OBD II solutions for after-market automotive products. Support for accessing vehicle parameters through OBD port – supports CAN, K-Line, J1850 physical interfaces

     

    OBD2 software stack Factsheet:

    OBD-PDF-Image

    This OBD2 software stack handbook serves as a quick guide to understand our ready-to-deploy OBD2 solution for diagnostic and emissions control applications in passenger vehicles.

    Download this OBD2 factsheet PDF to get following information:

    • Deployment of OBD2 solution in Automotive ECU, Tooling and Telematics Applications
    • OBD2 licensing model, our business engagement model, and OBD2 stack package overview
    • OBD2 Features, platform details, OS compatibility and memory requirements
    • OBD2 software stack development, testing, support and maintenance services provided by our Automotive Product Engineering Services team

     

    ISOBus / ISO 11783 stack

    ISOBus/ ISO 11783 stack is an extension of J1939 stack. This is designed to meet the needs of agricultural and off-road vehicle market.

    Our embedded developers have developed this stack to ensure easy integration with agriculture and off-road vehicle applications

    Following are some success stories of ISOBus stack integration

    • Design and development of ISOBus stack for agriculture tractor-based application
    .

    ISOBUS software stack Factsheet:

    ISOBUS PDF

    Our Automotive Embedded Software developers have designed this ISOBUS software solution is in compliance with ISO 11783 standard (defined for agricultural and forestry based tractors & implement applications)

    Download this ISOBUS software stack PDF to get all the details about this pre-tested and proven solution

    This ISOBUS factsheet/handbook contains the following information:

    • ISOBUS licensing fee, our business model, and ISOBUS software stack overview
    • Benefits of our unique offering – customer gets the owenership of ISOBUS IP rights and source code
    • ISOBUS solution package, features, memory requirements, configuration & customization
    • ISOBUS software stack Integration, testing, maintenance, support services

     

    J1587 stack over J1708 physical layer

    J1587 stack over J1708 physical layer is used in commercial vehicles for vehicle communication and diagnostics services.

    Our embedded automotive developers have designed complete J1587 stack and is readily available for integration with customer’s application

    Following are some success stories of J1587 stack implementation

    • J1587 stack solution for after-market automotive product. This solution was designed over J1708 physical layer to support access to the vehicle parameters
    .

    Calibration protocols

    We have experience in integrating CCP and XCP protocols for automotive ECU calibrations. These protocols are integrated to ECUs like body control modules to facilitate calibration

    Following are some success stories of calibration protocol integration

    • CCP integration with Engine Control Unit
    • XCP over LIN integration with roof control system
    .

    Boot loaders

    Our developers have in-depth expertise and experience in providing solutions for end of line reprogramming – this include design and development of boot loaders for electronic control units (ECU) and tooling applications to facilitate reprogramming

    We have boot loader solutions compatible with the following automotive protocols

    • J1939 (over CAN)
    • UDS (over CAN, LIN)
    • KWP2000 (over CAN, K-Line)
    • Custom (over Bluetooth, SPI, Serial/UART)

    Flash Bootloader Factsheet:

    Flash Bootloader-PDF-Image

    Our Flash Bootloader software is a time-tested solution. It has been deployed ( in more than 5 years) in automotive production programs across US, India and Europe.

    This is a stable and ready-to-deploy flash bootloader solution compatible with application-level protocols like UDS, J1939 and KWP2000.

    Download this Flash Bootloader PDF to get following information:

    • What you get with the Bootloader Solution Kit: Script & Tools development, Primary and Secondary bootloader
    • Know about all the Bootloader solution features and memory requirements
    • Compatibility with different vehicle communication protocols