Monthly Archives: May 2020

How WWH-OBD is Steering On-board Diagnostics Towards Harmonization: An Inside View

On-board Diagnostics, popularly known as the OBD, has been at the helm of vehicle diagnostics since the early 80’s. Made mandatory in almost the entire automotive industry, OBD was adopted very rapidly among the OEMs.

However, due to the lack of standardization, most OEMs developed their own regional version of OBD. Although, they were built on an identical concept and architecture, the services, parameters and methods were totally different. In other words, if these distinct OBD systems had to interact with each other, compatibility issues would creep in.

Over some decades, the automotive OEMs, organizations like ISO and SAE and other stakeholders have been pushing for standardization in the development of automotive components. And that included On-board diagnostics as well. Around 1996, the second version of OBD, called the OBD II was launched with some enhanced services (Modes), PIDs (Parameter Identifiers) and Diagnostic Trouble Codes (DTCs)

But was the OBD II enough for a vehicle’s on-board diagnostics considering advanced features such as Telematics where external entities would also interact with the OBD system? Or was a world-wide harmonized version of OBD required?

We got in touch with one of our automotive experts to reveal the answer!

Let’s start with understanding, what is WWH-OBD?

How do you Define WWH-OBD in the Simplest of Terms?

As the name suggests, Word Wide Harmonized OBD is a standardized version of on-board vehicle diagnostics and is based on the ISO standard- ISO 27145. It was established by GTR (Global Technical Regulations) to push for a more enriched version of OBD system. Theoretically, the Unified Diagnostic Services (ISO 14229-1) was included to the vehicle’s on-board diagnostics system.

The WWH-OBD standard enables the communication between the vehicles OBD system and the external test equipment. And like many other communication and diagnostics protocols, it is based on the 7-layered OSI model.

Let’s examine the WWH-OBD architecture closely.

• The Application Layer comprises the diagnostics services specified in ISO 27145-2 (common data dictionary) in reference to the Unified Diagnostic Services (ISO 14229-2).
• The Presentation Layer which is responsible for data translation and encryption/decryption, is also based on the ISO 27145-2 standard. It is in reference to other standards as well, such as SAE J2012, SAE J1979, SAE J1939-73, etc. Some legally binding Diagnostic Fault Codes and data definitions are enlisted in these standards which is mandated to be implemented in the On-board diagnostics system.
• The Session Layer is managed by UDS (ISO 14229-2).
• Being a harmonized protocol equipped to be implemented for modern automotive applications, the Transport and Network Layers assume much importance here. Diagnostics over CAN (ISO 15765-2 and ISO 15765-4), DoIP and ISO 27145-4 (communication between external tester and vehicle) are integral part of these layers.
• The Data Link Layer is specified with reference to CAN data link layer, DoCAN, DoIP- Wired Interface as per IEEE 802.3
• The Physical Layer is also quite diverse as it supports CAN BUS protocol, DoIP (Wired Vehicle Interface based on IEE 802.3) and DoCAN.

Why was the Need Felt for a World-Wide Harmonized OBD?

The answer lies in the name of the new protocol- World-Wide Harmonized. Over the past years, the automotive ecosystem has been the taking the route of standardization. AUTOSAR is the best example. Moreover, a trend of standardization has also been felt in the Transport Protocol as well as diagnostic protocols. Unification of diagnostic services in the form of UDS (ISO 14229) is again a classic example.

It is only natural to bring about the much-needed harmonization for the on-board diagnostic system. However, there are certain technical aspects to it as well.

The OBD II provides access to the information of status of Powertrain ECU and Emission control module. Any Diagnostic Trouble Codes (DTCs) recorded for these control units are also accessible from OBD II system. In addition to these, certain vehicle information can also be fetched.

However, there is a limit to the scope of OBD II. With only 10 modes dedicated to mostly the emission related information, a lot of diagnostic related information gets left out. Over a period of few years, a unified diagnostic service (UDS) has been at the helm of off-board diagnostics to enrich the diagnostic data from vehicles.

A host of vehicle information like odometer, seat-belt warning, etc. are being handled by UDS. Designed to be a comprehensive and unified diagnostic protocol, UDS has 20+ modes and naturally, it has access to way more information than OBDII.

With WWH-OBD, the UDS services are made available within the OBDII system. And that’s how the harmonization is being thrown into the equation. Along with UDS, few additional protocols such as Diagnostic over CAN (DoCAN- ISO 15765-2/4) and DoIP (ISO 13400) are also the part of the Transport and Network Layer of WWH-OBD.

What is the Difference Between OBDII and WWH-OBD in terms of Architecture?

It’s quite clear from the diagram which additional components have been included in the WWH-OBD architecture. However, the most prominent ones are the UDS (ISO 14229) at the application and the session layer, DoIP at the transport and network layer and ISO 27145-4 (WWH-OBD- Communication between Tester Tool and Vehicle).

So far so good! We discovered a lot in detail about the WWH-OBD and the need for its inception. And that brings us to the question; is it worth the effort and hype?

What are the Advantages of WWH-OBD that the Automotive Industry is hoping for?

Of course, WWH-OBD has a host of benefits when it comes to managing the on-board diagnostics of a modern-day data intensive vehicle system.

For starters, it has access to a higher range of data types. The OBDII PIDs are only 1 Byte long which leaves it with only 255 unique data types. WWH-OBD PIDs can be longer (Up to 3 Bytes). This translates into more available vehicle data.

Another value-add of WWH-OBD over OBDII is the enhanced detailing of the fault codes. In comparison with the 2 Byte DTC in the OBDII, WWH-OBD expands it to 3 Bytes. The 3^rd byte gives the failure mode of the fault.

The Failure Mode provides additional information about the fault in terms of severity, class and the status of the fault.

• Severity tells you about how urgently you need to get the trouble checked in a garage.
• Class is defined as per the GTR specifications. It indicates the group that the current fault falls under.
• Status of the fault indicates whether the fault is confirmed, or the fault has been completely tested during a driving cycle.
• The Malfunction Indicator Light glows in different ways as per the rating of the severity class.

During these times when safety is the highest priority among OEMs and suppliers, such features really help.

How do you see WWH-OBD fit into the Future of Automotive Diagnostics?

Diagnostics has and always will be one of the most crucial aspects of vehicle system. And WWH-OBD only seems to make it more robust, comprehensive and reliable.

Its just a matter of time when WWH-OBD will completely replace OBDII as the on-board diagnostic system; not only as a more reliable diagnostic protocol, but also as a harbinger of standardization and harmonization in the automotive industry.

IoT in Healthcare – Connected Devices, Telemedicine and Remote Monitoring

IoT or Internet of Things is all about expanding the ability of the internet beyond computers and smartphones. It has transformed into a system that integrates the internet, digital machines, and devices with specialised identifiers for functions across multiple industries.

IoT has revolutionised the realm of healthcare by providing continuous health monitoring services. With IoT in the healthcare market, patients do not have to depend solely on hospital visits for understanding the status of their health conditions. They can go for remote medical treatments and consultations effortlessly. Physicians are able to offer superior quality healthcare through IoT as they can continuously monitor the progress of their patients’ health.

IoT-Enabled Devices for Medical Treatment

IoT uses technology in smart devices to connect to apps for tracking the health of individuals. There are many devices and wearables that make the lives of patients a little better.

Some of these include smart clothing, smart medication bottles, smart glasses, pulse oximeters, computer vision technology, fitness bands, fitness trackers, digital stethoscopes, moodables, connected football helmets, hearables, etc.

An important feature of using IoT in connected devices is that physicians can ensure patient compliance. When physicians prescribe medicines and associated dosing schedule, they can monitor whether patients are sticking to the schedule with the help of connected medical devices.

Examples of IoT applied in connected medical devices/connected healthcare

• Monitoring of temperature for vaccines remotely
• Sensors for air quality
• Sleep monitor
• Sleep tools for infants
• Transferring tools for medical data
• Monitoring of drug effectiveness
• Vital signs data capturing
• Biometrics scanners for remote care
• Reminder technology for refilling medication

IoT in Telemedicine

Telemedicine powered by IoT is helping patients get excellent healthcare through real-time treatment. This is especially beneficial to elderly patients as most of them prefer to avoid hospital visits for doctor consultations.

With the help of advanced household gadgets such as voice-activated smart speakers, patients can stay at home and take care of their health. They can order drugs without physically having to go to stores by using devices such as Alexa.

Challenges related to IoT-powered telemedicine

Some of the main challenges related to IoT in healthcare are collection of data, checking the authenticity of the data, maintaining data security, and wearability of IoT devices.

The latest IoT-powered devices for telemedicine come with advanced sensors. Manufacturers are also focusing on building user-friendly devices. To make sure that remote treatments with doctors are effective, companies making IoT devices for medical treatment and doctors need to explain to the patients how each device should be used. To address the wearability issue, doctors now give live online coaching to patients.

In terms of collecting and storing data, new generation IoT devices come with good wearables so that the patients’ vitals are collected accurately and can be accessed by the doctor on time. This ensures safe availability of patient data.

With the help of IoT-powered telemedicine, doctors can track body temperature, sleep schedule, daily activity, seizures and other serious medical conditions too.

IoT in Remote Patient Monitoring

Across the globe, monitoring patients remotely has been possible through IoT. Utilising home-based devices and smart sensor technology, a patient’s health is monitored continuously, and timely treatment can be provided for emergency health issues.

IoT is also increasing mobility among patients as they are getting more involved in the treatment. With the help of fitness bands and other devices, patients are being increasingly motivated to improve and maintain their physical and mental health.

Remote patient management ensures that there is high-level digital security as patient information is extremely confidential. Moreover, the physical safety of patients is maintained through constant tracking so that they avoid falls or injuries. This increases hope and positivity among patients and they are inspired to take the necessary measures to recover.

Primary Advantages of IoT in Healthcare

• Quicker diagnosis: IoT-enabled monitoring devices perform constant tracking of patients and this helps in diagnosing diseases or health issues at an early stage.
• Decrease in expenses: With IoT, a patient can get high quality real-time medical consultations without actual visits to the doctor, hospitalisation, and re-admissions. This will reduce the healthcare expenses of the patient. Hospitals can also remove unnecessary system costs since monitoring is done remotely.
• Better access to healthcare in remote villages and towns: Villages and towns in some countries do not have enough access to cutting-edge healthcare services. Hospitals and governments can collaborate to leverage IoT for providing good healthcare services to such regions.
• Reduction in manual errors: Data collected by connected medical devices are error-free. This improves the overall quality of diagnosis in this domain.
• Better medical treatment: Since doctors can monitor patients on a continuous basis through IoT-powered medical devices, there is more scope for specialised and customised treatments. Doctors and hospitals are also able to deliver high customer satisfaction as patients are more engaged in the follow-up processes after treatment.
• Efficient management of medical equipment and medicines: With IoT, medicines and medical equipment can be effectively managed, and this prevents inefficient usage.
• Identification of side effects at early stages: The technology used in IoT is advanced and helps in identifying the side effects of medications at earlier stages. This is very beneficial to both the physician and the patient. The physician can change the medication and treatment promptly before the condition gets worse.
• Benefits to health insurers – Health insurers can use data collected through these connected healthcare devices for their claims processing and identify fraud claims. It also ensures that claims are handled with full transparency. Some insurers may also give rewards to policyholders who use IoT devices that monitor whether the user has adhered to the treatment guidelines during the recovery phase.

Summary

By applying IoT in the healthcare sector, we are building a preventative and proactive healthcare system instead of just offering reactive treatment when illnesses are diagnosed. The entire health system is focussing on prevention so that individuals do not have to suffer the harsh consequences of diseases.

Smart monitoring systems help in detecting symptoms quickly and treating them on time. This is great for both physicians and patients as the stress is reduced immensely. Moreover, patients can receive personalised treatments with the help of IoT-enabled devices as doctors can get a clear picture of their lifestyle and case history.

Adaptive AUTOSAR vs Classic AUTOSAR: Which Way is the Automotive Industry Leaning?

Software is critical to modern automobiles. The ever-increasing complexity of automotive embedded electronics results in huge amount of data collection and processing in real-time. Is Classic AUTOSAR platform equipped for this? What is Adaptive AUTOSAR? Can Classic and Adaptive AUTOSAR co-exist? Let’s Find out!

Case for a New AUTOSAR Platform: The Adaptive AUTOSAR

Let’s start by taking a stroll in the lanes of automotive history! Roughly in 1980’s the automotive industry welcomed its first electronic control unit. Back then, the ECU was responsible for controlling the air-fuel ratio, variable valve timing and a few other engines related stuff. Software embedded inside the ECUs were simpler in terms of size, complexity and computing prowess.

Fast forward to 2020, we are inching closer and closer to perfecting autonomous driving. Today, there is telematics, infotainment clusters and a whole bunch of IoT gizmos embedded in a vehicle.

But how do you integrate so many components, possibly from different vendors, without facing compatibility issues? AUTOSAR is the answer to this!

When AUTOSAR was introduced in 2002, the idea was to bring about a standardization in the development of automotive software. It was designed to implement ECUs which had software deeply embedded in them. It was assumed that these applications would not require any kind of update during its entire lifetime.

However, there has been a sea-change in the automotive software ecosystem. Automotive software now requires frequent updates. Additionally, there is a need for flexibility and computing prowess that has never been felt before. And Classic AUTOSAR platform is not designed for this.

This does not mean that the good old classic AUTOSAR has become obsolete; rather, it needs a brother-in-arms that can cater to the changing needs of future generation automobiles.

Let’s Analyse the Need for the Adaptive AUTOSAR Platform in 3 Cases:

Case 1: ADAS: Advanced Driver-Assistance System is based on an intricate set of sensors like LIDAR, RADAR and high-resolution cameras. The data collected from these sensors need to be processed to create a model of the environment outside of the vehicle. Based on this environment model, ADAS assists the driver during braking, parking or even driving (as in the case of autonomous driving).

In fact, autonomous driving has been the biggest drivers of the introduction of a new AUTOSAR architecture that can support dynamic communication, a flexible and secure platform, faster data communication and processing, and more.

A Moment in the Life of an Autonomous Vehicle:

• Observe the environment outside the car very minutely using sensors and cameras
• Communicate with the environment such as traffic lights, other cars, etc.
• Utilize the data collected from the sensors to make driving decisions such as left/right maneuver, slowing down, sudden braking, and so on..

The images captured by the cameras and the RADARS in an autonomous car must be transported to the ECU for processing in real-time. To achieve such fast communication, in-vehicle BUS System like CAN, LIN, Flexray, etc. is not enough. Ethernet takes precedence here and is bolstered by modern protocols like SOME/IP.

Case 2: Vehicle Architecture: When we talk about Vehicle to X communication (V2X) or vehicle-to-vehicle communication, we are looking at a completely modified vehicle architecture. Unlike traditional control units which are directly connected to sensors/cameras, a new concept of Domain Controller Architecture is trending in the automotive domain. Instead of using separate Controllers, a powerful controller is assigned for each domain such as Body Control, Infotainment, Powertrain.

In the case of Electric Vehicles, the communication between the charging station and the vehicle is also unique and must be secure for billing purpose. A strong commuting power is a must here too. And Classic AUTOSAR platform is simply not designed for such computation requirements.

Case 3: Firmware-Over-The-Air Update (FOTA): Most of the software embedded inside the ECU never require updates. A few that do require the updates have to be brought to the garage for the same.

Classic AUTOSAR is capable of providing FOTA services, but it is not best suited for it. Also, it is not possible to update individual applications inside an ECU. The flexibility issue along with stringent real-time requirements of Classic AUTOSAR also make it less reliable for FOTA.

Adaptive AUTOSAR’s flexible integration environment enhances the capability of the software to be updated and extended with new features.

A Comparison Between Classic and Adaptive AUTOSAR

A Snapshot of Classic Vs Adaptive AUTOSAR Architecture

Can Classic and Adaptive AUTOSAR Co-Exist?

As many would think of it, Adaptive AUTOSAR is not meant to replace its Classic counterpart. Instead, they are meant to co-exist in an automotive ecosystem. As both the platforms provide solutions to different problems, their co-existence gives a plethora of value-adds.

Even a modern vehicle loaded with ADAS and Telematics features, require Functional ECUs to handle an entire range of tasks (where hard real-time is mandatory). Where the Adaptive AUTOSAR would support dynamic communication for OTA upgrade, Classic AUTOSAR would provide high-safety applications deeply embedded in the ECU.

As the foundation of both AUTOSAR architecture is almost similar, there are provisions for interoperability between them.

The figure above shows how Classic and Adaptive AUTOSAR can co-exist in a vehicle

The major change that Adaptive AUTOSAR brings to a vehicle architecture is the use of Ethernet all across the communication network. The adaptive ECUs will communicate over the Ethernet while the Classic ECUs will still be communicating over vehicle BUS networks such as CAN or LIN.

So how will the Classic and Adaptive ECUs communicate with each other?

The answer is, through the gateway ECU. The classic ECU acts as a gateway and packs the signals from the BUS system into a service that Adaptive ECU can read. A conversion of configuration format is, however, necessary in this scenario.

There is another scenario where the Classic ECU is purely signal based and cannot pack the signal into a service. Here, the Classic ECU converts the signals into UDP frames and transmit them over the Ethernet. The adaptive ECU is equipped with a ‘signal to service’ mapping feature to convert UDP frame to service.

What Does the Future Hold for AUTOSAR?

The moral of the story is that Adaptive and Classic AUTOSAR complement each other and can co-exist! While Classic platform specializes in the functional ECUs where software is deeply embedded (has scores of benefits), Adaptive platform is the futuristic one that can help realize autonomous driving functionality. And the automotive industry needs both of these in equal measures.

There could be a time when Adaptive AUTOSAR platform is used as the sole platform for ECU software development. But it’s too early to predict that.

For now, with flexible gateways, automotive engineers can only think of joining these worlds and making the most of it.

What Makes FMEA a Must-Have Analysis During ISO 26262 Safety Lifecycle

ISO 26262 document lays a lot of emphasis on inductive analysis. As a matter of fact, it is a required activity for all ASIL grades (ASIL D to ASIL A). And although, ISO 26262 does not specify which Inductive Analysis to perform, FMEA comes up as a very obvious option. Not only because it has been used across industries to find the failure modes and their impact, but also due to its efficiency and maturity as a proven method.

In our latest vlog, we will talk about FMEA in the context of automotive Functional Safety.

Being a qualitative analysis, FMEA does not provide the FuSa experts with any metrics but goes a long way in identifying the different ways, a fault can occur and the impact it may cause. However, it does help in improving the Risk Priority Number (RPN).

There are multiple inputs to the process of FMEA that help in identification of the failure modes and their local as well as system effects. The vlog primarily discusses these inputs.

Key Takeaways from the FMEA vlog:

• Why is FMEA required?
• Different inputs to identifying the failure modes
• Example of an FMEA report

FMEA is one among the many safety analysis activities that is performed during the safety lifecycle. We hope that you like this vlog. Stay tuned for more such videos on ISO 26262 and Automotive Embedded landscape.