Today's vehicles are increasingly complex. Some cars, in fact, have over 100 electronic control units (ECUs) to support advanced driver assistance system (ADAS) functions and other features that rely on sensor input, like parking assistance and power steering.
Adding to the complexity, present-day vehicles feature multiple communication buses with directly wired sensors, actuators, lights, and controls.
In the past, a vehicle's software was simpler to define and design. The software often ran from a single computer, with a dedicated wire connected directly to a sensor and an actuator.
Today most of the changes occurring in the vehicle are happening via software, according to Brett Hillhouse, Global Automotive Leader, AI Applications, at IBM this month.
"Now all the software is interacting on these networks where everything is being shared," said Hillhouse, in a live Tech Briefs presentation titled Transforming Automotive Engineering by Tackling Complexity.
The meshing of software and mechanics requires a collaboration between two engineering teams that perhaps, in the past, could manage to remain separate.
"Where software and electrical engineering is converging is the most complex place, and it's also one that can use additional attention and focus," said Hillhouse.
So, in this increasingly complex environment, what should these mechanical and software engineering teams have at the top of their to-do list?
Two Tech Briefs readers had the following questions for Hillhouse. Read his edited responses below.
"Are new requirements and regulations for over the air updates impacting vehicle architecture and complexity?"
Brett Hillhouse: We're seeing new regulatory items popping up, like WP.29, and it is adding a new dimension to the systems architecture. It's truly the "system of systems" architecture, which includes some of the offboard capabilities found in the cloud, from a connected perspective.
There's also complexity on the testing side. I have to test against the various configurations before I can give an over-the-air (OTA) update back into the vehicle.
We're working with clients both on trying to understand the regulation, help them manage the compliance, and then understand how the two tool chains need to work together better to support the OTA environment. It's certainly high of mind.
"With increasing levels of complexity, how does the team prioritize which items need to be addressed?"
Brett Hillhouse: This is a good engineering question.
First of all, I think in most cases, everything has to be addressed. so it's about the prioritization: What do you spend your time on? And a lot of the process that the engineering teams in automotive go through is certainly in prioritizing items that they have to get right: automotive safety integration levels ( ASIL ), the whole ISO 26262 process .
The other important priority, I'd argue, is what is new: the new functionality that you think is going to be the most difficult and require the most reasoning and effort. The functionality that typically needs some more iteration.
When we just are looking at it from an engineering complexity perspective, those things that are new and complex, and that are cutting across multiple different domain or different ECUs, or different software functions, those are the ones that we typically see our clients clearly prioritizing and trying to get right before they get to system tests.
What are your automotive test questions? Share them below.
Transcript
00:00:01 Hi! This is the first video of a playlist for beginners on Functional Safety in the automotive sector. If you want to learn Functional safety from scratch, you've come to the right place. [Music] I'm Erwin Petry, I'm a functional safety expert for the automotive field at Kugler Maag. I consult automotive companies on the
00:00:29 application of ISO 26262. I give training on functional safety and i perform functional safety assessments. I hope you can profit from listening to this video. Okay, in brief: Functional safety is a general approach to making car electronics
00:00:50 safe. For this purpose, the international standard ISO 26262 contains guidelines to protect us road users, drivers and pedestrians from injury caused by faults in vehicle electronics and software. This video gives you a very condensed overview of functional safety and the standard.
00:01:18 We all know that today's road vehicles include more and more software. Of course, modern software enables us to incorporate useful new features into vehicles. Let's think, for example, about the cruise control feature or future autonomous driving. But I'm sure you also know examples of software
00:01:39 causing problems. Software can harm people and endanger all road users. Take the uncontrolled acceleration of a vehicle, for instance. One simple software fault could lead to a tragedy. Functional safety defined by ISO 26262 aims to reduce the risk of software and
00:02:04 electronics to a very low level that society finds acceptable. Now, in this video, I will introduce you to the formal structure of ISO 26262 road vehicles functional safety. The up-to-date second edition of the standard consists of 12 parts. I'll explain how you can safeguard the functional safety of your products
00:02:31 by using these parts together. Part 1 defines vocabulary to achieve a common language and interpretation of the content of the other parts. Here, you'll hear terms such as hazard analysis and risk assessment, safe state and freedom from interference for the very first time. Part 2 addresses functional safety
00:02:59 management. According to ISO 26262, you have to work in a structured and methodical manner in order to achieve functional safety. This includes ensuring that you have defined and actually applied development procedures. You also need a trained safety manager.
00:03:21 He or she is in charge of planning and managing safety activities. Create a so-called safety case. This includes a well-founded argumentation on why your system is safe. Do not underestimate this task! You need an independent person who confirms your argumentation. This principle is mandatory to prevent
00:03:49 misinterpretation and cheating. Parts 3 to 7 of ISO 26262 give guidance on different phases and disciplines from the early concept stage to the junkyard. The structure of different parts follows the V-shape of the system development life cycle. Part 3 is called the concept phase.
00:04:16 This early stage of vehicle and feature development is typically performed by the car maker. Development starts with defining the scope which is called the item in ISO 26262. Then, we come directly to our first real functional safety activity. Perform a so-called hazard analysis and risk assessment.
00:04:41 With the HARA, you judge the risk to human life if your item is faulty. Based on this risk, you define a set of so-called safety goals for your item. These goals are higher level safety requirements to be met. They all get an automotive safety integrity level:
00:05:04 ASIL A, ASIL B, ASIL C or ASIL D. Classify your item as ASIL D, if the risk is on the highest level. Take adaptive cruise control, for example. This item would typically be ASIL D. An electronic window lift where you just risk pinching your fingers, would probably be ASIL A.
00:05:30 The determined automotive safety integrity level accompanies you for the rest of the life cycle. The majority of necessary safety activities for your item depend on the assigned ASIL. In fact, under ISO 26262 they are more or less strict about
00:05:49 things you have to do and how systematically things are done depending on the identified risk. What follows now, is that safety goals must be addressed as one important aspect along with development. At the vehicle level this means that, based on the safety goals, a functional safety concept and functional
00:06:13 safety requirements must be developed. The purpose of this concept is to describe the principles of detecting faulty situations and how to react in such situations. For example, the airbag should be deactivated as soon as a safety mechanism detects that it is no longer working correctly. [Music]
00:06:37 Once a functional safety concept has been developed by the car maker, the various suppliers now come into play with system development on the next level. Typically, the suppliers create a technical safety concept for their area of responsibility which includes technical safety requirements.
00:06:58 Safety mechanisms are put in place to implement these safety requirements and are often an interaction between hardware that detects errors, software that determines responses and then hardware again that performs the response such as to de-energize a circuit. What you require on a system level has
00:07:24 to be implemented on a hardware and software level. These are parts 5 and 6 of ISO 26262. Detail your safety requirements for both engineering domains, hardware and software development. Remember the V-model: Don't forget to consider testing on all levels. Especially, test and validate the safety
00:07:50 mechanisms and the functioning of your safety concept at a system and vehicle level, before you switch on the assembly line. You must therefore note that ISO 26262 contains a number of requirements and methods that influence the usual development process at a system,
00:08:10 hardware and software level in detail. In parallel to the development, safety analysis must be carried out to produce a precise understanding of the causes and effects of faults and thus safeguard the design. Your responsibility doesn't end when development has finished. That's why we come to part 7: Production,
00:08:35 operation, service and decommissioning. It's often necessary to check that the electronics have been produced and installed safely. Repairs in workshops must not pose a safety risk. ISO 26262 requires planning accordingly. The field observation process is also intended to ensure that defective parts are
00:09:03 examined to determine whether there are deviations from the safety concepts and whether the software needs to be updated or hardware replaced. So far, we have made a quick run through the vehicle lifecycle. So - there's some time left to consider the remaining parts of ISO 26262.
00:09:26 Part 8 is labeled supporting processes. In fact, you'll find a number of very different topics here which have to be taken into account at various points in the life cycle. For example, there's configuration management. Configuration management is similar to that required under Automotive SPICE. Part 10 of the standard contains
00:09:52 explanations for better understanding. This part is just for information purposes, but it's helpful. Part 11 gives very detailed help on the use of semiconductors and microcontrollers in safety related systems. Finally, part 12 has been added specifically for motorcycles.
00:10:14 It essentially contains information on how to carry out a hazard analysis and risk assessment in a way that makes sense for bikes. Okay - that was an overview of ISO 26262! What have we learned? Here is my summary of things you should definitely remember. Functional safety prevents people from harm caused by malfunctioning
00:10:40 electronics. That's the reason why this standard exists and why it's relevant for you if you are involved in the development of electronics for vehicles. Please keep in mind! First: Your development steps and efforts depend on the ASIL whereby the ASIL is the result of a
00:11:02 hazard analysis and risk assessment. Second: Develop a safety concept with safety requirements. Do this for your scope of responsibility. Such concepts and requirements describe how to detect faults and how to mitigate them. Third key lesson: Implement
00:11:29 and test these requirements on all levels. Each involved company must contribute here. Depending on their responsibility, be it on a vehicle, system hardware or software level. Fourth point: Perform safety analysis to understand the causes and effects of faults. Number five:
00:11:56 Have an independent person confirm the results of important development activities. Number six: Provide an argumentation for safety in a safety case. Seventh: Functional safety requires appropriate measures to assure functional safety throughout the whole lifetime of vehicles. And the last key
00:12:22 lesson to remember: There is no functional safety without safety management. After this video, you should have an idea of what functional safety in automotive is all about. If you want, you can also download a free white paper corresponding to this video. Use the link below and download our
00:12:45 white paper. This video was only an overview. I would like to refer to our other videos which go into further depth on a whole range of topics. For example: Functional safety management, hazard analysis and risk assessment. which topics would you like to know more about? Watch our corresponding video or subscribe to one of our training
00:13:08 courses. Thank you for your attention!
