×

Happy to Help!

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

Great, thanks!

Monthly Archives: March 2018

  • 0

The Story of How Car Seating System has Evolved and Role of Automotive Electronics

Innovation in automotive over the course of almost 150 years has been phenomenal. Cars have become safer, speedier and more comfortable.

However, there is one very important part of the car where the evolution has not been very gradual but off late, it is getting all the attention it deserved.

Yes, we are talking about the seats! During the first phase of the evolution of the cars, emphasis was more on the engine, powertrain, and chassis. Simultaneously, electronics was also being introduced in the cars to make the control units and systems more fail-proof and intelligent.

However, the automotive OEMs in collaboration with tier-1 suppliers of automotive components also have been gradually investing in the car seating control systems in order to deliver a value-add driving experience to their customers

In-fact, gradually the automotive Seating solutions are being perceived as one of the important brand differentiators.


Automotive Seating Control Solutions
Source: Continental Automotive

The Striking New Changes in Car’s Seating Systems

  • Customizable Multi-way Adjustable Seats: Gone are the days when the seats could only be adjusted in 2 ways and that too manually with a lever. The new multi-way adjustable automotive seating solution are operated by buttons that can adjust the seats just the way you like. Ford Motor Company’s Lincoln Continental has a 30-way adjustable seat without making the seat any bigger than the usual ones.
  • Stress & Fatigue Detecting Seats: There are automotive seating solution in making that measure heart rate and other metrics to deduce the stress and fatigue level of the driver and adjust the seat accordingly to enhance the driver’s alertness. Stress-relieving massage can be offered to the driver if he or she is feeling stressed. It is up to the passenger to accept the massage or decline it.
  • Smartphone Connected Seats: The list of components that you can connect your smartphone with, has a new addition. There are automotive seating solutions in the market that feature Bluetooth connectivity and make it possible to connect them with your smartphone. The passenger can then adjust the lumbar support, thigh and back bolsters, neck support etc. with the help of an app.
  • Customized Massage: In order to convert the seats to a ‘seating experience’, the seating control needs to be smart enough to cater to the users in a way they would like the most. Advance seats now come with customized massage pattern selector.
  • For instance, if the seat occupant wants a mild massage only at the lumbar region of the back, there is an option for it. Likewise, an end-user can opt for other such massage patterns. An end-user also has the option to choose the intensity of the massage.

    Embedded software companies have designed such products that can be directly fitted into the seating system of the car.

  • Memory Seats: It’s all about offering personalization to the end-users and why should the seating solutions be any different!. Memory seating solution is the perfect example of such personalization. These automotive seating system remember the settings for a particular user and implements it upon the users’ request. These settings are stored in the memory of the ECU responsible for controlling the seats.

Role of Electronic Control Unit (ECU) & Embedded Software

Whenever we talk about any kind of automation in a vehicle, there has to be Electronic Control Units (ECUs) solution that drives the automation.

These small embedded computers enable the communication between different components of the car using the vehicle’s bus network (CAN, LIN etc.)

In the seating control solution as well, the automotive ECUs have a major role to play. They are responsible for taking the input from the user and transfer the signal first to the car battery and then to the target component.

A specialized ECU called body control module is responsible for activating any kind of mechanical action that need to be performed to control any component of the seating system.

These automotive ECUs interact with each other using automotive communication and diagnostics protocols (J1939, OBD2, UDS, KWP 2000 and more) that are integrated  with the automotive ECU solutions. These software stacks are based on ISO standards and therefore, bring in the compatibility between automotive ECUs from different suppliers.

What’s the Future Like for Seating Control Systems?

The future of the seating solutions in cars will be personal rather than generic. With Artificial Intelligence teaming up with electronics, the seating control solutions will be designed to be smart enough to recognize the person sitting in the car and adjust to his or her preferences.

We can expect to witness even more futuristic car seating systems in the coming years as extensive research is already on in this field.


  • 0

Understanding the Automotive Functional Safety Best-Practices with ISO 26262 standard

The modern day vehicles have evolved from predominantly mechanical machine into an electronically-controlled system.

Today, a car consists of hundreds of automotive Electronic Control Units (ECU) and millions of lines of software code.

With passage of time and the lightening pace of technical advancement, the number of ECUs within automobiles is also increasing. This increase in complexity and functionalities of ECU-based car design is driven by a need for a comfortable driving experience along with safety and pollution control.

The automotive ECUs power many of the advanced function and features available in modern cars including advanced driver assistance(ADAS) , telematics, passive safety systems, engine management – to name a few.

Functional Safety in Automotive:

With the widespread of the modern automobiles, run and regulated by automotive ECUs, the need for advanced safety features has also become inevitable.

Functional Safety as a process has become an essential component of the ECU software development cycle. Functional safety schemes for automobiles helps in identifying malfunctions (electric and electronic), and specifies actions and techniques to be adopted to mitigate risks and damage during instances of software or hardware failures.

Inability or a delay in identifying or mitigating instances of ECU (hardware/software) failure can impact all the stakeholders throughout the value chain – including the ECU Supplier, Car manufacturers and the end user.

The consequences may involve loss of life or property, financial loss, legal liability, regulatory actions or even the loss of goodwill for all of those involved.

And this is why today modern vehicles are required to adhere to the safety standards listed within the Automotive Safety Integrity Level (ASIL). ASIL is a risk classification scheme specified within the ISO 26262 – a Functional Safety standard for Road Vehicles.


Functional Saftey Automotive
Image Credit: dcvizcayno.wordpress.com

Ensuring Functional Safety of Automotive Software with ISO 26262 standard

The ISO 26262 standard addresses the need for a unified and automotive-specific international Functional Safety Standard for electrical and electronic ECU and other embedded systems in a vehicle.

The ISO 26262 standard is an adaptation of IEC 61508 standard. It specifies recommendations to ensure the functional safety throughout the product development cycle- at the system, hardware, and software levels. The ASIL standard is a key component for the ISO 26262 compliance.

Most functions within an automotive ECU are implemented and controlled through automotive ECU software and the complexity of this software can reach more than 10 million lines of code.

Typically, these programmable ECUs contain highly modular embedded software. The software may include both safety-related and non-safety-related code and software components that perform functions with different ASIL ratings.

The ISO 26262 standard specifies two approaches to be followed if embedded software includes software components with varying ASIL ratings.

  1. Either develop the entire software according to the highest ASIL, or
  2. Take necessary actions to ensure that the software components with a with a lower ASIL rating are not interfering with software with higher ASIL rating


ISO 26262

Design and development of ISO 26262 compliant ECU Software

The need for developing safety-critical automotive components and the increasing demands for complex and innovative automobile applications are ongoing challenges for the automotive manufacturers and design engineers.

They have to play the balancing act of catering to increased application complexity while reducing the time-to-market with utmost care. And this while ensuring that no comprise is made on ensuring safety of the automotive application and software component.

The expertise then lies in designing the automotive ECU application by taking into account every aspect of safety failures that can occur during the product development cycle. These failures mostly fall under following groups:

  • Random/systematic hardware defects
  • Systematic software defects.

Identifying Sources of Errors during ECU Software development Lifecycle

The systematic software failures occur mostly due to human errors during different product development life cycle phases. These can mostly be traced back to a certain root cause and fixed.

Let us look at some instances of errors that usually occur during the software development cycle and which could have a lasting impact on the performance of the final automotive application:

  1. Requirement specification and communication– This phase results in one of the largest sources of errors. It occurs when:

    • Software executes “correctly” according to the understanding of the requirement, but the requirement eventually appears to be inaccurately defined within the scope of the system
    • The requirement was simply misunderstood by the automotive software developer
  2. Software Design and coding errors– Considered as the second most common source of errors, this type of error usually occurs due to :
    • A poorly structured embedded software code
    • Timing errors, incorrect queries, syntax errors, algorithm errors, error in displaying results errors, lack of self-tests, failed error-handling – to name a few
  3. Errors due to software changes – Such errors is said to have occurred when
    • Changes to the developed software may introduce unanticipated errors
    • Failure of the configuration control process

    These errors can usually be traced back to requirements and programming errors.

  4. Errors due to inadequate testing: During the testing phases, sometimes the software seems to have passed the testing criteria, but during the actual execution it may fail to perform the required task. Such a failure is termed as a testing failure. This happens if:
    • Software functions properly in unit testing
    • Software passes systems and integration testing, but ideally it shouldn’t have. This happens when safety-critical test coverage is inadequate

    Such errors can also be traced back to requirements and programming errors

  5. Errors in Timings: Software performs the right function, but at the wrong time or under inappropriate conditions.

    Such instances of errors during the application development can be reduced or eliminated by introducing failure-safe processes and by taking extra care at each of the phases including: requirement analysis, design, manufacturing process, documentation etc.
    Designing a robust and well –optimized software, keeping into account these instances of errors; can reduce systematic failures to a large extent.

Recommended Approach

The best practice for developing functionally safe automotive software can vary with the end- application and requirement it is being developed for.

The development and design of a software specific to ADAS may not be same as the one for Anti-Lock Brake System (ABS). The need of the hour then is to optimize the software and hardware design according to the specific domain and application.

The ISO 26262, a functional safety standard for automotive, specifies definite techniques and measures to address various types of failures and issues related to the automotive software development lifecycle.

It is also necessary to ensure that while designing the ECU software and ensuring compliance with the ISO 26262 standard, the components (hardware and software) are not seen just as individual systems but as a whole .The best approach is to have a holistic view of the ECU application so that all the applications work in perfect coordination.


  • 0

KWP 2000 and UDS Protocols for Vehicle Diagnostics: An Analysis and Comparison

Vehicle diagnostics as a process has undergone numerous transformations over the past 2 decades. The demand for a more accurate, standard and efficient fault detection in vehicle diagnostics, has led to breakthrough innovations and developments.

Evolution of Vehicle Diagnostics:

Earlier, there were flash codes wherein technicians had to look for flashes and convert them to codes or sometimes the technician had to physically remove vehicle components, disconnect wires for fault detection.

The increasing complexity of vehicle systems over the time mandated the need for diagnostics standards to efficiently track their scope and relevance.

To cater to this need of the hour, various vehicle diagnostic protocols were conceptualized and developed.

ISO and SAE (Society of Automotive Engineers) introduced various diagnostic protocols and standards, designed to cater to the different types of automotive ECU systems and diagnostics specifications from the vehicle manufacturers.

OBD II (On-Board Diagnostics), K-Line per ISO 9141-2, KWP 2000 (Keyword Protocol 2000), UDS (Unified Diagnostic Services) are some of the vehicle diagnostic protocols designed and deployed during the evolution in off-board and on-board vehicle diagnostics.


Evolution of vehicle diagnosis
Image credit: nextews.com & brezan.nl)

Although a large number diagnostics protocols and  systems were developed and used within the automotive industry, many of them have become obsolete due to the rapid “Electronification “of the automotive ECU (control units).

As of now, Keyword Protocol 2000 (KWP 2000) and Unified Diagnostic Services (UDS) remain one of the most widely used vehicle diagnostics protocols.  Let us have a look at two protocols in detail:

KWP 2000:

KWP2000 or the Keyword Protocol 2000 is an on-board diagnosis (OBD) protocol complaint with ISO 14230 standard.

It defines a common set of communication codes, for exchange of data, used by vehicle ECUs as per the guidelines the OBDII regulatory standard. KWP 2000 is compatible with both K-Line (ISO 9141) and CAN (ISO 11898) in-vehicle networking systems.

The KWP 2000 protocol uses a physical layer, identical to ISO 9141-2, for bidirectional serial communication over K-line with the controller. The protocol also uses L-Line (optional) unidirectional communication, to wake up the automotive ECU.

The average data rate of KWP 2000 is between 1.2 and 10.4 kilo baud, and the data fields within the message may contain up to 255 bytes.

UDS protocol – Unified Diagnostics Service:

The Unified Diagnostics Services protocol (ISO 14229) is an off-board diagnostic system. It is designed in compliance with ISO 14230-3 (KWP2000) and ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN)) standards.

The maximum size of message supported within UDS is up to 8 bytes. For exchanging messages exceeding 8-bytes, the UDS protocol uses ISO 15765-2 layer, an international standard for transfer of data packets over a CANBus.  UDS diagnostic implementation is independent of the underlying physical layer and is also compatible over both LIN and CAN in-vehicle networks.

UDS as a diagnostic protocol was developed to unify all the diagnostics standards that existed previously and to come up with a single valid set of diagnostic services for the automotive ECUs.

This has ensured that integration of the UDS protocol stack reduces the additional costs for the development of diagnostic communication applications.

Comparison Between KWP 2000 and UDS Protocol:

While, UDS protocol can be seen as a superset of the KWP 2000, since it is derived from the latter, a comparison of both as the diagnostic protocols gives out some interesting facts:

  1. Support for in-vehicle communication networks: The KWP 2000 protocol supports CAN and K-line bus systems . The UDS protocol is designed to be independent of the underlying vehicle network as it supports a range of bus systems including CAN, CAN -FD, LIN, etc.

    KWP 2000 is highly preferred where the vehicles are based on legacy systems such as K-line. Otherwise, these days UDS protocol is the go to standard for vehicle diagnostics.

  2. Transfer of Key Measurement Values: Both the diagnostic protocol facilitate exchange of request and command messages from the test equipment to the automotive ECU; and key measurement values (data) in response from the vehicle ECU.

    But, there is a key difference between the two protocols in the way these measurement values are exchanged between the tester and ECU:

    UDS uses the 2-byte dataIdentifiers (DID), whereas the KWP uses a 1-byte recordLocalIdentifier and 2-byte commonIdentifier.
    The advantage of the UDS protocol is that the tester can request several measurement values with one UDS service request using its 2 bytes ( 16 bits) long data identifiers as compared to the 1-byte ( 8 bits)  Local identifier used by KWP 2000 standard. This means increased efficiency of data exchange.

  3. Diagnostic Communication between Test equipment and vehicle ECU: The exchange of messages between testing device and the vehicle ECU forms the basis of the diagnostic system.

    The natures of request and response messages and data transfer interval between them form an important factor in vehicle diagnostics.
    KWP2000 favors symmetrical communication sequence where the number of request and response messages between the testing device and server are symmetrical.

    On the other hand, UDS is based on an event driven and periodic communication sequence. This means, the number of request and response messages can be different.
    Moreover, in a periodic communication sequence based on UDS standard, the test equipment sends periodic requests for updated information from automotive ECUs. This helps in closely monitoring vehicle condition in regular intervals. The vehicle ECU may respond to the periodic request with one or several data record values.

    This also helps in identifying any deviation from the threshold/ideal values associated with crucial vehicle functions such as airbag deployment , engine fuel injection, engine speed and heating etc.
    Thus UDS offers more detailed information related to the fault through periodic update.

  4. Error Memory Management: While the KWP 2000 provides 4 services for error memory management, the UDS protocol specifies just two services.

    KWP 2000 uses following services for error memory management:

    $14 (clearDiagnosticInformation),
    $18 (readDTCByStatus),
    $17 (readStatusOfDTC), and
    $12 (readFreezeFrameData).

    While, UDS uses only the

    $14 (clearDiagnosticInformation) and
    $19 (readDTCInformation)

    With the help of the readDTCInformation service in the UDS protocol , the testing device can not only read diagnostic related DTC data, but it can also read additional parameters of the component ( say engine)  at the time of the occurrence of fault. This helps in pinpointing the root cause of fault/damage and then undertaking the right repair and maintenance operations.

  5. Read DTC Subfunctions: The KWP2000 protocol specifies 3 function for the Read DTC ( Read DiagnosticTroubleCodes) service . On the contrary, the UDS protocol specifies 21 sub functions for the Read DTC service.

    With the help of the additional sub functions, UDS enables the tester to collect more diagnostic information. This is useful in the modern automotive industry where the complexity of design and number of components in the vehicle are increasing.

KWP and UDS- A Quick Comparison:

Parameters KWP2000 UDS
ISO Standard Compliance Is based on ISO 14230 Is based on ISO 14229-1 and is derived from ISO 14230-3 (KWP2000) and ISO 15765-3.
Protocol Dependency KWP 2000 functionalities for measurement value transfer and error memory management were improved for UDS standards. It is an extended version of KWP2000 on CAN (specified under ISO 15765-2) and many other previous diagnostic standards.
Tester-ECU Communication: Supports a symmetrical number of requests and response between the tester and the ECU(s). Is based on event-driven and periodic services. Hence number of requests and response between the tester and the ECU can vary.
Transfer of measurement values: Involves a 1-byte “record Local Identifer” and  another 2-byte  “Common Identifer” Involves 2-byte data identifier and allows higher number of IDS to be exchanged.
Error Memory Management: Specifies four services for the error memory management:
$14 (clearDiagnosticInformation),
$18 (readDTCByStatus),
$17 (readStatusOfDTC), and
$12 (readFreezeFrameData).
Specifies two services for error memory management: $14 (clearDiagnosticInformation) and
$19 (readDTCInformation)
Read DTC Functions KWP2000 specifies 3 subfunctions under the ReadDTC service UDS specifies 21 sub functions under the ReadDTC service
Vehicle Network Supported Runs on several transport layers such as K-line (serial) or CAN. It is independent of the vehicle bus systems. Runs on CAN, LIN, and Ethernet on transport protocol.
ECU Identification Contains a specific function to identify the ECUs – Read ECUIdentification Doesn’t include a separate service to identify the ECU, rather this functionality is included within the Read databyidentifier.

Reference: Road Vehicles: Diagnostic Communication : Technology and Applications- By Christoph Marscholik, Peter Subke

KWP 2000 and UDS are both used in modern automobiles for efficient and accurate diagnosis of vehicle health and faults. Over the time, UDS protocol owing to its robustness and a broader service spectrum is expected to be the future of automobile diagnostics.

UDS protocol is defined by redundancy of functionalities whereby various UDS services can be used to execute a certain diagnostic function. For example, both SIDs 0x36 (TransferData) and 0x3D ( writeMemoryByAddress) are effective for flash memory programming. Similarly, any of the 0x2E (writeDataByIdentifier) and 0x3D (writeMemoryByAddress) can be used for data manipulation within ECU.

Thus, UDS as a diagnostic protocol paves way for added services and functionalities. But it also calls for additional requirement for ECU memory along with extra development costs. Thus it is important to ponder over certain questions, before deciding on the implementation of UDS services for your application, listed as:

  • What services are necessary for you?
  • What sub functions and parameters are important to be considered for UDS implementations?
  • What data identifier and parameters should be focused on?

If you take these questions into account, you will be able to successfully implement UDS within your automotive application without any unnecessary development costs or efforts. Talk to our Automotive experts to know how you can seamlessly implement and integrate UDS software stack according to your automotive use-case.


  • 0

How IoT is Enabling New Opportunities in Solar Energy Harvesting Projects

solar energy harvesting project
Clean and renewable source of energy is the need of the hour. Solar energy is one of the most abundantly available renewable energy sources on the lines of wind and tidal energy

Sincere efforts to tap this form of energy are being put in across the world; but there are roadblocks.

Many solar energy harvesting projects are coming up with the help of government and also under public-private partnership.

When we talk about solar energy, various environmental factors come into play that affects the overall output of the photovoltaic cells. Changing position of the sun, wind speed and direction, system down time etc. are some of them.

The list of many such factors is long. This has a direct impact on the efficiency of the solar energy harvesting projects. And efficiency or the Solar Energy output is the most critical factor that defines the success or failure of investments in solar energy field deployments.

This is where emerging technologies like IoT can play a pivotal role. We will first discuss some of the challenges that come along with green energy sources and then explore the solutions that Internet of Things (IoT) can provide.

Challenges in Tapping Solar Energy to its Maximum

The biggest challenge we face while trying to tap green energy is its instability. In a large solar energy harvesting project, the issues are complex and require more than the technical acumen to resolve.

For instance, the position of the sun keeps changing throughout the day and the static solar panels are not able to adjust to the changing position of the sun.

A solution to this problem can be a motor that rotates the panels but when the problem is scaled up to a thousand panels, this solution seems incomplete.

Furthermore, you need to be sure about whether the solar energy harvesting system is delivering optimum output at all times. The system should be smart enough to respond and adapt to the fluctuating weather conditions. Monitoring each panel can become a nightmare if your grid has thousands of such panels clustered together.

In a nutshell, more complex the system, more likely it develops issues that will be hard to fix.

How IoT Helps in Maximizing the Solar Energy Output

Solar energy harvesting industry is rapidly growing. If we go by the facts and the figures, the global solar energy industry is slated to reach $422 billion by the year 2022, growing at a rate of 24.2 CAGR.

Infact, the solar energy capacity is increasing at a rate of 40% worldwide. However, in order to reach the set solar energy goals, the solar grids need to be more optimized and high on efficiency. The loopholes need to be identified and measures need to be taken to rectify them.

Mechanical engineering and classical physics may not be the answer to all the woes that large-scale solar energy harvesting is experiencing. The innovation is now steering more towards an amalgamation of computer science and electronics. We are talking about the sensors and Internet of Things (IoT).

Let’s have a look at one of the scenarios in which IoT can work wonders for solar energy harvesting.

As we have earlier discussed, the solar panels are not able to tap the maximum amount of solar rays because the sun’s position keeps on changing throughout the day. Factors like wind speed and other weather conditions also affect the overall energy output.

‘Internet of Things’ addresses this problem with the help of sensors/actuators, IoT gateways and, other IoT components.

solar energy harvesting system
Source: BGR

We will discuss a use-case where the solar panels are adjusted automatically to the position of the sun throughout the day with the help of an IoT system.

There is a sun tracker system designed in master-slave architecture.

Sun tracker (a microcontroller) is fitted to an actuator which in turn is fitted to the motors that move the solar photovoltaic panels.

There is a sun position algorithm that determines the position of the sun at all instances of the day. This is a special algorithm that takes in data like latitude, longitude etc and computes the sun’s position based on the info.

The trackers also have IoT sensors that collect environmental data (such as wind speed etc.) and send to the master controller.

The master controller sends the signal to the solar tracker for initiating or stopping an action. This component also receives the data from the sensors fitted on tracker controller using protocols like ZigBee, WiFi, etc. This data is directed to the cloud backend for analysis.

A SCADA based system is also a part of this system but as of now, we will focus on those parts that directly increase the energy output.

In this example of IoT enabled solar energy harvesting system, the actuators have a major role to play. They move the motors as and when signalled by the master and the tracker controller.

The result is that the solar panels always face the sun and are able to tap the maximum solar energy.

The data collected by the IoT sensors also help in a long run. They help the experts analyse the environmental factors that are still able to influence the energy tapping.

Changes in the sun position algorithm can also be brought about with such analysis that will further enhance the efficiency of the solar power grid.

Final Remarks

IoT technology framework can be a great value-add for renewable energy harvesting projects. This is because IoT enables a two-way flow of power and data in distributed networks.

The new-age industry grade IoT sensors are also built for on-site implementations as they can withstand harsh climatic conditions and have a very low power footprint.

When embraced properly, IoT technology can prove to be a disruptive innovation for solar and other renewable energy harvesting projects.


  • 0

Board Support Package Implementation and Configuration for Automotive Tier-1 Suppliers

 
About the Customer

We have partnered with reputed Automotive Tier-1 Suppliers and After-market companies, from the US, Europe and India, for multiple Board Support Package (BSP) development projects.

Following is the representative list of some of our successful global automotive engagements:

  • Europe based supplier of automotive components and accessories with strong focus on body electronics.
  • An India based global supplier of automotive components catering to Automotive OEMs and also the After-market segment.
  • An Electric Vehicle company who is looking to revolutionize the global electric vehicle space with its innovative projects.

 

Business Challenge:

The microcontroller platform, on which an embedded automotive product is designed, needs to interact with the operating system or the scheduler (depending on the use-case) and thus there is a need for low-level drivers and hardware abstraction layers.

Board support package contains these drivers and abstraction layer libraries. It helps the hardware to interact with the upper level modules (automotive applications).

Every hardware requires a different board support package for board-bring up. Additionally, customizations need to be made depending on the functions that the hardware is supposed to perform.

The challenge, in most of the BSP development projects, is to customize the BSP with the requisite low-level drivers and hardware abstraction libraries. Rigorous testing also needs to be done with each custom module that has been added to the BSP package.

Our Automotive customers partner with us for a Board Support Package development package, based on following requirements concerned with the microcontroller platform:

  • Number of ADC channel
  • Number of CAN channels
  • Number of PWM channels

In each of our BSP development projects, our team has been involved in customization of the BSP and robust integration of BSP solution with the microcontroller environment.

Our expert automotive software and hardware development teams have ensured seamless board bring-up during all our global engagements.

 

Embitel’s Solution:

We have developed an array of board support packages for various MCUs (Micro Controller Unit) including Fujitsu family, FreeScale family, IAR and a few other widely used MCUs in automotive industry.

Hence, we had a ready-to-deploy BSP that only needed a few customizations based on the project’s requirement.

Based on the SRS, we developed the drivers and libraries and integrated to the package. Other customization task was based on the target hardware platform and the number of CAN, ADC, and PWM channels.

 

Value-add Features of our Board Support Package Solution

  • Low-level drivers such as CAN, SPI, LIN, MCU, GPT and others integrated to the package.
  • HAL (Hardware Abstraction Layer)
  • Supports 8/16/32 bit microcontroller platforms.
  • Customized on the basis of target hardware platform.
  • Rigorous integration-level and module-level testing performed.
  • MISRA-C compliant code
  • Conformance test (with multiple test-cases) for LIN and CAN bus system.
  • Our low-level drivers can be developed for both AUTOSAR and non-AUTOSAR architecture.
  • Support at any phase of vehicle testing after BSP deployment if any issue arises.

 

Embitel’s Impact

Our ready-to-integrate Board Support Package reference solution customized to the target hardware platform was instrumental in fast board bring-up.

This reduced customer’s product’s time-to-market from 6 months to 2 weeks. The thoroughly tested BSP solution was able to reduce the power footprint considerably and also increase the boot-time.

 

Expertise in Tools & Technologies

  • Softune IDE, an Integrated Development Environment to develop programs for FR family of Fujitsu Microcontrollers.
  • CodeWarrior, an IDE to write program primarily for FreeScale microcontroller family and a few others.
  • IAR, a workbench primarily used for RENESAS microcontroller.
  • Greenhills, an IDE from Greenhills Software to develop BSP for PowerPC

  • 0

UDS Software Stack Implementation and Integration Projects for Automotive Customers

 
About the Customers:

Our automotive developers have collaborated with global customers – that include Automotive OEMs’ and Tier-1 suppliers for UDS based diagnostic solutions.

Our ready-to-integrate UDS software stack is in production programs of our following global customers:

  • Europe based Tier-I supplier of software engineering and debugging solutions for embedded systems
  • US based leading supplier of Automotive Roof Systems and Solutions
  • A German manufacturer of Electrotechnology and Automotive equipment with worldwide presence
  • A leading provider of Motor Control Software solutions, based in Germany

 

Business Challenges:

Since UDS protocol is a unified standard (consolidation of KWP 2000 and ISO 15765-3), it has been an integral part of all new product development programs of the global automotive players

However, the in-house technical teams are often confronted with challenges related to UDS software stack development and integration.

All this results in additional software development costs and customers lose focus on core product development activities.

To help our customers overcome these hurdles, Embitel has been partnering with their product development teams for UDS software stack integration projects.
 

Embitel Solution

Our pre-packaged software solution for UDS stack is customizable, to best suit your end-user application.

Embitel follows the V-Model Software Development Life Cycle for UDS Stack Implementation. This includes –

  • Requirement gathering and analysis
  • Architecture Planning
    • Creating High Level Design Diagram
    • Identifying the required software modules
    • Project specific Architecture Customization
  • Creating Module Level Design
  • Implementation of UDS software stack as per the customer’s system environment
  • Testing
    • Module Testing
    • Integration Testing
    • Functional Testing

 

Following are some of the features of our UDS stacks that have helped us deliver a value-add solution for our customers:

  • Static Enabling and Disabling the SIDs
  • Configurable DIDs configurable to meet the business and use-case requirements
  • UDS software stack is Portable to 8/16/32 bit microcontroller platform
  • Hardware independent stack

 

To successfully deliver UDS software implementation projects for multiple customers, our team has partnered for following software development services:

  • Implementation and configuration of UDS services, as per the ISO 14229 standard
  • Implementation of Diagnostic over CAN TP layer (as per ISO15765)
  • Implementation of Diagnostic over LIN TP layer (as per LINTP)
  • Implementation Diagnostics over IP TP layer (DoIP)Configuration of UDS stack for compatibility with RTOS or non-RTOS environment

 

In addition to UDS stack implementation; we have also partnered with customers for UDS software support services:

  1. Integration of the UDS stack to the hardware platform
  2. Integration of UDS solution with target application
  3. Development of bootloader software based on UDS standard
  4. Development of driver modules like CAN, LIN, Ethernet and more
  5. Verification & validation (testing services) of target application after integration
  6. Detailed Documentation Support (Creation of HLD, LLD, MISRA Report)
  7. Creation of PC based UDS tooling solutions

 

UDS STACK Image
 

Tools and Technologies Expertise:

  • STM32xx Micro Controller
  • Code Warrior IDE for embedded software development
  • CANoE and Freematics OBD Emulator
  • CAPL Script for ECU reprogramming

  • 0

How Body Control Module (BCM) Works in an Automobile

 
The features enabled by electronic modules in modern day vehicles have been increasing not only in number, but also in complexity.

This is primarily due to the increased focus of the global automotive industry stakeholders to deliver enhanced safety and comfortable driving experience to the end-users.

To achieve the above mentioned objectives, OEMs equip modern cars with features such as Anti-lock Braking System (ABS), power-controlled steering, power windows, turn indicators, Android Infotainment System and more.

These features are controlled and managed by Electronic Control Units (ECUs) that work independently.

All these ECUs, integrated within a vehicle, are also required to communicate with each other.

This inter-ECU communication is managed and controlled by a Body Control Module (BCM) unit.
 

What is the Function of Body Control Module?

Body Control Module in automotive, makes use of the vehicle’s bus system (CAN, LIN, etc.) to communicate with different ECUs in the vehicle.

This module can be considered to be the brain controlling different body parts (different ECUs) by sending and receiving signals through the nerves (vehicle BUS).

A BCM unit, which is also an ECU, acts as a gateway or hub in order to interact with different ECUs. This mitigates the need for cabled plug-in connection between ECUs within the vehicle.
 

Hardware & Software Components of Body Control Module Architecture

A typical Body Control Module ECU consists of a microprocessor to control the various functions of vehicle’s body electronics (power window, wiper, side-view mirrors and more).

Additionally, there are ports provided on the BCM platform for the purpose of communication with different ECUs, instrument cluster, sensors, actuators, etc.

Various other components can also be integrated to the BCM unit depending on the specific requirements and automotive use-cases.

The devices or hardware that connect to a Body Control Module ECU can be categorised into input and output devices:

  • Input Devices: Devices that feed data to the body control module and include sensors (potentiometers, variable resistors, magnetic pickup, etc.)
  • Output Devices: Devices that are tasked with generating a response to the signal received from the input devices (relays and solenoids are typical examples of output devices in the context of BCM)

We will talk about these in detail as we proceed.

Apart from the hardware components, the BCM unit may also require to be integrated with different automotive stacks based on standards like J1939, Unified Diagnostic Services (UDS), OBD2, ISOBUS and more.

APIs to enable the communication with the application layer are usually integrated with the BCM.


Body Control Module

The above Body Control Module block diagram indicates how the unit is connected to various input and output devices and the communication flow between these components.
 

How Does a BCM Control Unit Work?

Automotive Body Control Module is a multi-faceted electronic component that supports multiple functions, the foremost being the management of a gamut of automotive body electronics.

The body control module receives data from the input devices and controls the output devices based on this data.

For instance, when the user presses the power window switch, the car’s battery sends power to the BCM unit, to communicate with the ignition module. This, in turn, sends a signal to the load that will rotate the motor and control the window.

Likewise, there are innumerable body control functions that need to be performed smoothly and reliably. Controlling these parts would also be possible without a BCM unit; but that would amount to additional wiring inside the vehicle.

A body control module eliminates the need for this additional wiring. It also manages the flow of power so that the electrical module of the car does not get over-burdened when multiple functions are carried out at the same time.
 

Partner with Us for State-of-the-Art Body Control Module Solutions

Backed by 11+ years of experience in automotive embedded solution, at Embitel Technologies, we offer an array of Body Control Module (BCM) solutions and related services.

Enlisted and elaborated here are some of the key-features of our BCM reference design.

  • Component Level Diagnostics for All Inputs and Outputs: The ready-to-deploy body control module features component level diagnosis of all inputs and outputs that are received and relayed from the module. Component level diagnosis refers to confirming the integrity of all the sub-components and separate boards.
  • Prognostics (Service-related Info): The health of the ECUs and modules are constantly monitored and timely predictions of faults are ensured. This feature is related to vehicle service.
  • Front and Rear Lamp Load Control: The BCM communicates with the electric system of the vehicle by controlling the load drivers. These drivers then activate the relay and control the lamps.
  • Motor Control, Actuator Control and Solenoid Valve Control: The Body Control Module developed by Embitel efficiently controls the motors, actuators and the solenoid valves. All of these are the output devices connected to the BCM.
  • Rear View Mirror, Wiper and Window Control via LIN Subnet: In order to support all kinds of vehicle bus system, our BCM comes equipped with LIN subnet which can control wipers, windows, rear-view mirrors, side view mirrors, petrol lids and more.

The application layer is on top of the BCM. This layer has been developed based on MATLAB Simulink Model. The application layer has some algorithms that are needed for different purposes, depending on the use-case.

For instance, when a user tries to open the vehicle using a remote key, the radio receiver in the car receives the signal and sends it to the BCM in an encrypted form. The algorithm implemented in the application layer of the body control module processes this signal and initiates the mechanical actions to open the door.

Some of the algorithms implemented in the application layer are:

  • Trip Fuel Economy: Deduces the fuel used by the car in a trip.
  • Trip meter: Computes the distance covered during the trip as set by the user.
  • Fuel Level: Takes the data from the fuel tank sensors and calculates the fuel left in the tank.
  • Odometer: Shows the total distance covered by the vehicle.
  • Distance to Empty: Computes the distance the vehicle can cover with the available fuel in the tank.
  • Gear Advisory system: Decides the most appropriate gear to drive based on the current speed, and displays this information to the driver.

Additional algorithms can be implemented based on specific requirements.

 

Talk to Our BCM Experts Today

 


  • 0

Connected Retail Market is Set to Grow by 400%! A Sneak-Peek into IoT Use-Cases that will Drive this

Connected retail market is expanding as more and more retailers are connecting the value chain. This is evident in the new research from Transparency Market Research (TMR).

The report mentions that North America will have a strong demand for connected retail but Asia Pacific will also show a strong demand during this forecasted period.

In 2016 the connected retail market was estimated to be US$16.30 billion but the forecasts for 2025 is US$82.31 billion which is 400 % more than 2016.

The growth of connected retail is powered by all the sub segments in retail including the online segment which has grown tremendously in the recent years.

Adoption of IoT by retailers

IoT in retail has potential to disrupt end-to-end processes. Here are some of the many use-case of IoT in retail

  • data monitoring in real time from stores and deriving insights,
  • enriching the in-store experience of customer using the collected data and
  • Streamlining store operations.

Smartphones has paved the way for retailers to personalize the communication with the customer in-store and help them to strengthen their brand.

Recent increase in usage of beacons has also helped retailers to connect with the customer as they enter their store. Supply chain is the key area in which retailers are using IoT to streamline the supply chain operations.

79% of retailers globally are expected to adopt IoT which will definitely transform the retail industry.

L.L.Bean, an American retail company which specializes in clothing and outdoor recreation equipment, has taken the usage of IoT to another level by embedding sensors in coats and boots to collect data which will then be received by a blockchain system.

This information will be used by retailers to analyze temperature data, and how often customers wear and wash the clothing.

Key IoT applications in Retail

Below are few important areas in which retailers are using IoT:

  1. Store Management: Smart store management is key for optimizing the operations of a retail store. And Internet of Things (IoT) has potential to play critical role in enabling this.
  2. For example, IoT enabled monitoring of the refrigeration units. IoT sensors can help retailers to collect data about energy consumption, power failure and temperature variations. Analysis of this data can come in handy to reduce costs and improve efficiency.

  3. Logistics and Fleet Management: IoT enabled fleet management and telematics devices are being deployed for route optimization. Such applications help ensure better visibility of the goods on the move and reduce distribution time and cost
  4. Warehouse Management: Major retailers like Amazon are leveraging IoT based solutions for warehouse automation and digitize the fulfillment process.
  5. Human intervention is being increasing replaced with IoT enabled robotic devices for product handling, packaging and dispatch in the warehouse

  6. In-Store Experience: Converting the footfalls into sales has been the biggest goal and also a challenge for the global retailers.

    Increasingly retailers have embraced the idea of sophisticated in-store experience to achieve higher footfall conversion.

    To cater to this demand from retailers, IoT solution companies have designed products that ensure a seamless in-store shopping experience for the visitors.

    This includes geo-fence based products to deliver personalized offers and promotions, interactive kiosks to display store catalogue and answer FAQs’, omnichannel experience to provide best of online and offline shopping and more.

Conclusion

The demand for connected retail and the usage of IoT is going to grow multi-fold in the coming year and it’s important for retails to adopt the new technologies and provide a great user experience and streamline their operations.

Need help with implementing IoT solutions for your retail store, please connect with our experienced IoT consultant to book a free session.

To know more about the usage of IoT in retail and use cases please visit our detailed blogpost on Top 4 Internet of Things (IoT) Retail Use Cases and Examples