Why is Safety at the Core of Software-Defined Vehicles?

Why is Safety at the Core of Software-Defined Vehicles?

Creating technology can be a complicated and time-consuming process. At LHP Engineering Solutions, we provide just that: solutions. We are a services and technology integrator with the skill and expertise to solve your functional safety issues. One way we provide our clients with solutions is to introduce them to our advisory management model, the Functional Safety Ecosystem, a six-part integrated model with the power to move your company beyond compliance. Safety is at the core of software-defined vehicles, but true functional safety demands more than a simple mechanistic attempt to fulfill compliance requirements; LHP’s Ecosystem applies a more powerful holistic approach.

To understand why functional safety needs to be at the center of engineering for software-defined vehicles, we should first find an exact definition of functional safety. After that, we’ll look at some examples of functional safety interventions, and discuss what functional safety means for designers and executives in an automotive engineering organization. We will also examine LHP Ecosystem’s integrative approach to functional safety, and how it will cultivate not only compliance but excellence in your company’s designs and builds, from start to finish.

Table of Contents

• What is functional safety in automotive engineering?
• What are the differences between safety and functional safety?
• Why is functional safety important in engineering?
• What does functional safety mean for automotive engineers and executives
• LHP Functional Safety Ecosystem details
• Examples of LHP Functional Safety Ecosystem solutions
• LHP Functional Safety Ecosystem, a sum of six parts

What is functional safety in automotive engineering?

Functional safety is an aspect of safety management dedicated to diminishing risks from the malfunction of a device, process, or system within the interconnected and interdependent electrical and electronic (E/E) safety systems in modern cars and especially autonomous vehicles (AVs). The internationally accepted way to do this is outlined in the ISO 26262 standard.

Voluntary functional safety compliance is also a way for manufacturers to present AVs to the public which are worthy of trust, ahead of government regulations. Public trust in AVs will become increasingly important to the industry in the coming years, as the production of cars with higher levels of automation increases drastically. LHP’s Functional Safety Ecosystem places the public’s safety, and their confidence in the safety of those vehicles designed and built in compliance with functional safety standards, at the forefront of design concerns.

What are the differences between safety and functional safety?

Functional safety is a part of the safety practices of many manufacturers. Safety in general is a very broad topic. Functional safety is specific and held to a standard, ISO 26262: 2018 Road Vehicles – Functional Safety, in order to provide a consistent and uniform measurement of performance.

The idea of safety is really the idea of risk management, of ensuring that activity presents no reasonable risk. The exact amount of risk that it’s reasonable to accept becomes rapidly difficult to measure, or think about. Some examples:

• People require the risk of injury to be extraordinarily low. No one wants to consider the possibility of an injury to themselves, their loved ones, or another person.
• We might not also want to damage any public structures, our vehicle, or another person’s property, and also want the risk of this occurring to be very low.

We know intellectually that this chance, this risk, can never be absolutely zero, but we require our safety systems to strive for absolute zero, as the standard itself says, “an absence of unreasonable risk due to malfunction of E/E systems”. Consumers, operators, and passengers of automotive products maintain an expectation that the risks of injury or serious property damage will be completely eliminated, or at least so low as to not be present in everyday operation. Indeed, feelings are not the measurable stated objective of functional safety, but the public’s trust is not always based on statistics, even if it can be measured by them.

Humans have always and probably always will intrinsically make risk assessments. For example, we might examine a layer of ice on a frozen river; is it thick enough? Is it safe to walk on? We feel safe when we determine by various assessments, by our experience, or by trusting in the expertise of others, that the risk is very low – low enough that we feel comfortable walking on that ice. Similarly, to feel safe riding in an autonomous vehicle, consumers make their own assessments, partly by relying on the expertise of suppliers and carmakers to make the car as safe as possible, and they rely on the knowledge of experts like LHP to get them there.

In automotive engineering, the question is, will this system or device help to address a particular safety problem or issue? How will this system have to be designed in order to ensure an extremely low-risk level? Functional safety asks, instead, whether the risks presented by the possible failure of an individual system or component within a vehicle are low enough. Another way to say this is, do I find the amount of risk from this action acceptable or unacceptable?

To return to the frozen river analogy, safety itself might consist of inspecting the ice where you plan to walk. Functional safety involves considering not only the frigid water flowing beneath, but perhaps concealed hazards in the frozen surface, and also ways to exit the freezing river safely should the ice break beneath your feet. Functional safety ensures that the affected systems work together correctly and keep people safe. If they fail or fail to work together correctly, they should do so in a way that can be predicted and anticipated, so that even in failure these systems are performing within the envelope of eventualities the AI is programmed to deal with. The eventuality that a system or device might fail has to also be a part of functional safety.

Why is functional safety important in engineering a software-defined vehicle?

Functional safety as a standard guides the engineering and design of electrical and electronic systems, especially as they work together within not only the entire car but an entire connected network comprised of software-defined vehicles and their external navigation infrastructure while in operation.

Functional safety also introduces engineering quality assurance (QA) to the design process. QA tends to be very prevalent in the manufacturing side of an organization but is less prevalent when it comes to developing the product to be manufactured. Educating the QA team of the organization about functional safety is a good option.

What does functional safety mean for automotive engineers and leaders?

Understanding functional safety, and having awareness of its initial costs and ultimate benefits, can compel an organization’s leaders to decide to invest in compliance with full knowledge of the difficulties and advantages that come with that decision. ISO 26262 compliance efforts in the short term can lead to greater trustworthiness for an organization and industry longevity in the long term.

LHP Functional Safety Ecosystem and the software-defined vehicle

What is the LHP Functional Safety Ecosystem?

The automotive industry and in particular SDVs, with all the chaos of their emerging technologies, need standardizing benchmarks for their functional safety. These benchmarks not only ensure the vehicles are fully functionally safe, they encourage public trust in that safety. Widespread ISO 26262 compliance is a way to begin converging the industry and calming the tumult, but ISO 26262 is still only a beginning. Realigning the vibrant, disparate global organizations that are inventing new technology daily, and introducing real industry-wide agreement on baselines and conditions for the use of that technology, requires even more than simple compliance with one standard, demanding as that standard may be. Understanding functional safety, and the LHP Functional Safety Ecosystem’s role in standard compliance, certification, and beyond, is the way forward for suppliers and manufacturers to compete in this complex and emerging new global market.

LHP began with ISO 26262 and built our unique Ecosystem on that foundation with six crucial focus areas. When used as a total functional safety environment for not only compliance but superior quality, this is a powerful tool.

The six areas of focus

The LHP Functional Safety Ecosystem is composed of Cybersecurity, Test Systems, AUTOSAR, specific Standards and Regulations, Model-Based Development, and Application Lifecycle Management. We can examine and discuss each in detail below.

Cybersecurity:

Security and safety must work side-by-side in the Functional Safety Ecosystem; security is an elementary component of building trust. A software-defined vehicle with billions of lines of code has an equal number of vulnerabilities. No matter how robust a system may be in its design regarding safety, it might still be susceptible to malicious action by a hacker. ISO 26262 reinforces that functional safety is impossible without a sufficient cybersecurity presence in the design and function of electrical and electronic systems. However, ISO also does not include any guidance for how to implement cybersecurity in the ISO 26262 standard. The LHP Functional Safety Ecosystem supplements this gap with an understanding of SAE J3061 (Cybersecurity Guidebook for Cyber-Physical Vehicle Systems) and ISO/SAE 21434 Road Vehicles – Cybersecurity Engineering.

Test Systems:

Case study download. Automated testing systems are a key component to standardization and ultimate safety since system testing and validation are at the heart of design and development. LHP’s automated testing systems aid in rapidly testing and validating electronic control units (ECUs). This greatly speeds up time to market, saving valuable development time. From designing customizable test systems to consultation to providing a full-authority engine control system (ECS), LHP offers a full range of test system services. These are a crucial part of the Functional Safety Ecosystem as a whole.

Automotive Open System Architecture (AUTOSAR):

AUTOSAR is not a standard in its own right, but a developmental partnership made up of certain automakers and suppliers. The partnership was formed to create standardized, open, software architecture and a standard development platform for creating software used in electronic control units (ECUs) found in modern vehicles. Vehicles are increasingly defined by their software. For example, over-the-air software updates are able to fix problems as well as remove or add capabilities to the vehicle quickly and easily. This means adhering to software architecture standards is even more vital for suppliers and developers.

Günter Reichart, the autosar.org spokesperson, has said,

“If a company does it alone it is one proprietary solution. If it is shared and used by several partners it becomes technology, and with broad application, it becomes state of the art and alleviates certification.”

This is the case: AUTOSAR is now in widespread use. Because this standardization allows the chance to speed up development, automate software testing, and scale the software to different platforms, it is of great interest to functional safety.

While LHP does offer standalone AUTOSAR training, AUTOSAR truly belongs at the center of an organization’s functional safety effort. LHP Chief Technology Officer Steve Neemeh has said, “AUTOSAR is really a software platform, and functional safety has specific standards for software platforms, so don't have an AUTOSAR team -- have a team that develops AUTOSAR that's functional safety compliant (full video).” Of course, the best way to do this is through LHP training as part of the 6-point LHP Ecosystem!

Model-based development (MBD):

MBD must be seen as a necessity in the area of developing functional safety processes for electrical and autonomous vehicles. This is an invaluable tool for validating the designs of SDVs. Model-based development allows designers to simulate conditions their system will encounter on the road, giving them time to detect, manage, and correct issues before a design is manufactured, allowing faster code generation. Prototypes will be safer once they are built because the simulated tests have already proven the designs. A case study detailing LHP’s work with a customer’s MBD structure can be found here.

Standards and regulations

These not only bind developers and engineers to specific design conditions and considerations, but they also provide consistent criteria for their organization’s adherence to those considerations (i.e., functional safety). This act of holding to a high standard of performance is a way to win the public’s trust. LHP’s education efforts and work packages help organizations understand not only the core standard for functional safety (ISO 26262) but also the adjacent standards like IATF 16949 and ASPICE (now the standards ISO/IEC 33001 and subsequent), even fairly new standards, like ISO/PAS 21448. Developers and executives alike must recognize the importance of maintaining a fluent comprehension of these standards, and how this is critical to keeping functional safety at the center of your engineering organization.

Application Lifecycle Management (ALM):

Modern cars and automobiles of the coming years will be defined by the software they left the factory with, as well as the software they receive throughout the vehicle’s existence. Application Lifecycle Management is a way for developers to manage and control software applications from the first iteration through to the end of an application’s life. Functional safety implementation requires, for traceability, a defined process. Well-executed ALM helps ensure that the organization’s customers are getting the best software for their needs, by helping align the work of the development team to the application’s end goals. See the case study for an example of LHP’s ability to help ensure your product’s safety, and your organization’s functional safety compliance, through LHP’s Application Lifecycle Management training.

Examples of LHP Functional Safety Ecosystem solutions

A partner like LHP can provide direction in this rapidly changing industry for companies thinking about seeking guidance. We provide the expertise to help take the mystery out of the ISO requirements and simplify the methodology of reaching compliance. Some examples of the guidance available with LHP’s Functional Safety Ecosystem:

• Finding and fixing previously undetected software bugs as a result of implementing functional safety processes.
• Identifying and helping to close gaps in software development that might have been known but not addressed, or possibly not known at all.
• Verification and validation testing: assisting companies in navigating the testing and documentation requirements of functional safety.
• Assist in developing internal processes and upgrading design considerations in hardware to achieve ISO 26262 compliance.

The LHP Functional Safety Ecosystem, a sum of six parts

We conclude with a thought from the LHP e-book, Implementing Functional Safety:

“ISO 26262 contains a lot of information, making it sometimes difficult to see the forest instead of innumerable trees. This can be a barrier to the launch of functional safety efforts, especially for small organizations. But, with a map and an escort, it is much easier to find the right path, accelerating the process from years to months.”

LHPES can provide the map, and we can escort your company through the ISO 26262 process, guiding you through the maze of information and requirements from start to certification, so that your organization is prepared and well-positioned to take its place in the software-defined vehicle future.

Interested in learning more about Software-Defined Vehicle for your organization? Contact our team today!