Automotive functional safety ISO26262

Welcome to our second blog post of functionalsafetyfirst.com on Cybersecurity. In our previous article, we introduced you to some of the key ISO 21434 terms and applied them to the well-known Jeep Cherokee cyberattack. For those who may have missed it, you can find it here . In this article, we will explore additional ISO 21434 attack-related terminologies, using the same Jeep Cherokee cyberattack as example.  Attack related terms! - Weakness & Vulnerability Weakness - is a defect or flaw in an asset that can cause undesirable/unwanted behaviour. Examples: Missing requirement or specification Missing/Incorrect implementation of security protocols such as Media Access Control Security (MAC) for communication among ECUs in vehicle network Using outdated software without the latest security patches makes vehicles vulnerable to digital break-ins, as attackers may already know and exploit these security gaps A weakness of an asset may or may not lead to a vulnerability. For example,...

Welcome to our first ever blog post of functionalsafetyfirst.com on... Cybersecurity !! Cybersecurity in vehicles is evolving faster than ever — and much like functional safety, it’s become a non-negotiable pillar of modern automotive development. It’s no surprise that functional safety engineers are now exploring ISO/SAE 21434, while cybersecurity experts are diving into ISO 26262. The two worlds are converging rapidly. But if you’re a functional safety engineer stepping into cybersecurity for the first time, where do you start? How do you get comfortable with the “cyber language” — the new terms, the lifecycle, the regulations, and the mechanisms like encryption, secure boot, secure OTA, and intrusion detection? This article is our attempt to make that journey simpler. In this article, we will introduce you to a few terms used in the ISO 21434, with short relatable examples. Towards the end, we will look at applying these terms to one of the most prominent and publicized remote hacki...

  How important is the DIA? This was the question one of our team members asked us when we started reviewing a DIA. It is a simple yet profound question, for there are a lot of nuances to be unpacked as part of the answer. << Assumption for the article: We are standing in the shoes of a Tier-1 supplier. For a Tier-1, their customer is the OEM. This implies that the DIA will be between the Tier-1 and OEM FuSa managers. >> Straight up, the DIA is the first document with which we start discussions with the customer. The discussions on the DIA should ideally start at the RFI/RFQ stage itself. Starting the DIA at the RFI/RFQ stage ensures that the work products agreed upon with the customer are properly estimated (time and money) during the quote. This, in turn, means that the Tier-1 is able to plan their work accordingly. As an example, we had an OEM who asked us to perform FMEDA calculations for an ASIL-A program. (I’m sure you are all aware that FMEDA becomes mand...

We were recently guiding the Software team of an organization, on writing Software Safety requirements (SSR). During a review, we asked them if they have written the Safety-relevant QM requirements in the SSR document. The Software team was surprised - " Should we write QM requirements in an SSR document? Shouldn't that not be done in a separate requirements document as per QM process? ", they asked. " Yes and No " - we said. " Depends on which type of QM it is ". " What do you mean by type of QM? " they raised their eyebrows, puzzled. In this article, we will explain the many shades of QM Requirements, and what kind of "QM" requirements must be written in a Safety requirement document (be it a TSR, SSR or HSR). Please note that ISO 26262 never talks about different types of QM explicitly, and the ideas shared in this article is coming from our experience. Broadly, QM Requirements can be classified as follows -  Non-Safety-relevant ...

With the recent announcement from Ministry of Road Transport and Highways, to mandate ADAS for heavy vehicles, India has taken a lead in the path towards safer highways. In the below document, we cover more ground about the mandated features and the implications for OEMs and Suppliers to meet these new regulations.  

  One of the things that we are proud of as a team is our ability to handle safety programs in crisis mode and bring them to a good shape in a short span of time. We have done it so many times in the past (When we were working in Tier-1 organizations) and as well recently as part of Drivvize to our clients that we have come to a point where we are able to crystalize our thoughts & actions and provide it as actionable steps to the broader community. In the below Mind Map, we have tried to capture our methodology of working through a safety program crisis. The following things have been assumed: We are speaking about Tier-1 projects only! Tier-1 is in-charge of both HW & SW development HW metrics are applicable Capable engineers are available to perform the safety activities (BIG BIG assumption!!) Note: Article written using NI (Natural Intelligence). No AI tools were harmed during the making of this article!!

Software component qualification (ISO26262-8, clause 12) is an activity widely used with the intent of reusing existing software for Safety. In our first article , we had discussed the big picture view of component qualification with the analogy of a jigsaw puzzle. In this second part of the article, we will cover the following topics: The broad steps that need to be carried out for SW component qualification Challenges in qualification and possible solutions The broad steps that need to be carried out for SW component qualification  Let us consider the example of a component qualification performed for a Math library that is proposed to be used in an ADAS system that has Safety goals which demand Math libraries to be safety relevant. Let’s assume that only the code for the Math library exists.  The Qualification activity could be broadly broken into 3 steps. Defining safety-relevant requirements and testing them Defining the Integration/User guide and performing Integration t...

Software component qualification (ISO26262-8, clause 12) is an activity widely used with the intent of reusing existing software for Safety. This article is covered as 2 parts and will cover the following topics: What’s the big picture view for component qualification? Why is it performed? A simple jigsaw puzzle analogy to understand the activity The Thumb Rule for Component Qualification Different perspectives of the qualification activity The broad steps that need to be carried out for SW component qualification Challenges in qualification and possible solutions This is Part-1 of the article and will cover topics 1-4 above. Part 2 of this article will cover topics 5 and 6. What’s the big picture view for component qualification? Why is it performed? When it comes to developing the software of a safety-critical system as ASIL, there are mainly 3 approaches. Developing the entire software of that system according to the highest ASIL level of that system Developing only some parts of th...

There is a saying that “ Well begun is half done ” which means a clearly understood scope of work and a well-defined plan makes the work easier. There are some key activities in Functional Safety that must be “Well begun”. Let us understand the key aspects of functional safety (FuSa) management in this article.  The foundation and pillars must be strong to build a safe house. To build a safe 'Item', the foundation and pillars that must be strong are: FuSa Process DIA (Development Interface Agreement) Safety Plan Safety Case The above picture represents a high-level Functional Safety framework.  This Framework Starts with DIA – to define the scope of work Progresses with Safety plan – to define the strategy how to perform the work  Ends with Safety case – to argue the achievement of Functional Safety compliance. This framework represents FuSa Process as the "Foundation" of FuSa Development, DIA as the Input to the Complete FuSa cycle and Safety Case as its Output. Safe...

What is the difference between an operating system that is ASIL B Compliant vs ASIL D Compliant? What does an ASIL D Operating System additionally need to provide in terms of “features” compared to an ASIL B Operating System? Let us keep aside the process aspects of ASIL B vs ASIL D development and focus only on the technical aspects. To keep the focus on Safety, we have discussed in the context of RTOSs and not HPC OSs. Irrespective of the ASIL level that needs to be achieved by an Operating System, there are some basic aspects that an RTOS needs to provide such as: High availability and reliability - Guaranteed and correct execution of Safety tasks Maximum Performance - minimal latencies for interrupts, events, tasks etc Guaranteed Isolation of Safety related processes and its memory Guaranteed freedom from Interference (FFI) for Safety related tasks/threads Safe and reliable inter-process/inter-task/inter-thread communication Error handling related to Application’s use of the OS and...

One of the best things that has happened in the last few months (After starting Drivvize ) is the chance to speak with a lot of companies who are getting started on their safety journey. Apart from being able to work on new technologies, it also gives us a sneak peek into the concerns and problems facing these companies with respect to FuSa implementation. What we have tried here is to consolidate the broad categories of issues faced. We have also tried to look at it from a 10,000 feet view to arrive at solutions that could be applied for most of these issues.  A word of caution: We recognize that every organization is unique and hence there could be some variations to the problems faced. Due to these variations (Ex: Process compliance levels, organizational maturity, organizational structure etc.), some fine tuning or customization of the broader solution will have to be done to get the solution to work.  Common Questions and General Observations and our proposed solutions: 1...

Quite often, Safety Engineers are confused between Functional Safety requirements (FSR) and Technical safety requirements (TSR).  What level of details are to be provided in both the requirements and where exactly to cut the boundaries between these two is unclear. We will discuss the same in this post. Requirements Hierarchy Functional Safety Requirements (FSR) are derived from Item definition, HARA and Safety goals and are traced back to Safety Goals. Each Safety goal shall have a minimum of one FSR associated with it. Technical Safety Requirements (TSR) are mainly derived from FSRs. Each FSR shall have a minimum of one TSR associated with it. The below image provides a hierarchical view of requirements/activities flow from ISO26262 Part 3 – Item definition to Part 5 Hardware Safety Requirements (HSR) and Part 6 Software Safety Requirements. Also visit our YouTube video which explains the flow of Functional Safety requirements. Difference between FSR and TSR This table gives the...