DEV Community: Anton Rysin

Software-Defined Vehicle: The Potential and Reasons to Keep It in Check

Anton Rysin — Sat, 26 Aug 2023 23:28:16 +0000

Since the early days of the appearance of vehicles, people have constantly improved them. Naturally, along with improved performance, came additional complexity. In the first place, the vehicle was a purely electronic-mechanical device. Shortly after the start of the rapid improvement, computer systems and software were added to it, respectively.

This article covers the topic of the evolution of autonomous vehicles to software-defined vehicles, the intricacies of the process of the transition from one to another, and safety and security implications.

The Role of Software in the Evolution of Autonomous Vehicles

At the very beginning of the vehicle development journey, hardware was dominant in the industry. However, the state-of-the-art machines imply a much more convoluted system: it includes an increasing number of vehicle functions in the areas of vehicle control, body and security, Active Safety, and other comfort, convenience, and connectivity services. As a rule, it is a convergence of hardware and software functionality.

Thereby, electrical/electronic architecture, or E/E, is the essential component when it comes to the automotive industry. Nowadays, the architecture of controllers and software is moving towards centralised control, meaning that most OEMs (original equipment manufacturers) are now in 4th generation — Domain-centralised E/E architecture. Historically, there are 5 levels of E/E architecture, from the latest one to the first:

How Software-Defined Vehicles Are Disrupting Traditional Automotive Design

If looking closer into hardware-defined vehicles, the functions of their architecture are determined by the properties and capabilities of the hardware strictly. As one can see in the table, the first-generation vehicles work according to the simple scheme: 1 device = 1 function, without the possibility of improving the functions of previously released vehicles. This leads to the fact that a vehicle released, say, 5 years ago is significantly inferior in functionality to a newly released one, even if their hardware is capable of the same performance.

With software-defined vehicles, on the contrary, their functions are determined by the installed firmware of the vehicle, which in turn allows adding new functions or improving previously installed functions on previously released vehicles without changing the hardware.

Examining Safety and the Security Implications of Software-Defined Vehicles

However, despite all the advantages of a Software-Defined approach to automotive manufacturing, like any other technology, it can be prone to illegal violations that demand corresponding Safety and Security regulations. Here are some examples of such violations that have happened in the last decade and a half:

2010: Ex-Employee of dealership Texas Auto Center remotely disables 100 vehicles by triggering their immobiliser. The dealership used a Webtech Plus system as a means of repossessing vehicles that have not been paid for. The employee allegedly wanted to take revenge for his dismissal.
2015: Hackers take remote control of the Jeep vehicle. Two researchers managed to remotely hack a car on the highway, turning on the wipers, blasting the radio, and disabling the engine to spot the vehicle.
2018: University researchers circumvent key fobs of Tesla Model S and can unlock/start the vehicles in 2 seconds. By figuring out its encrypted codes, they were able to crack the key fob.
2019: Researchers extract personal data from a Tesla Model 3. By accessing the particular car’s computers, they managed to find 11 driver phonebooks complete with numbers, email addresses and calendar entries.
2022: Researcher manages to hack Toyota's Global Supplier Preparation Information Management System gaining read/write access to the global user directory containing 14k+ users.

For certain, these cases have encouraged particular actions to be taken in terms of security. According to the 2023 State of Automotive Software Development Report issued by Perforce and Automotive IQ, “30% of those surveyed cited safety as their top concern in automotive software development”, meaning that the comparison to the last year’s report revealed several notable shifts:

The top concern is directed at demonstrating functional safety compliance.
Suppliers are aimed more at meeting ISO 26262 requirements rather than just complying with a coding standard.

However, coordinating safety requirements can be a challenge, especially in cases where some suppliers are new to this area, given the increasing number of contractors supplying components.

In this sense, there is another option for how to deal with Functional Safety and Cyber Security. The 2022 NHTSA Guidelines assert that “the automotive industry should follow a robust product development process based on a systems-engineering approach with the goal of designing systems free of unreasonable safety risks, including those from potential cybersecurity threats and vulnerabilities”. How do we define what risks are reasonable and what are unreasonable?

A day-to-day interpretation and a legal interpretation may differ. Engineering does not perform a legal interpretation but follows Enterprise Risk Management Frameworks and analyses the risk based on state-of-the-art methodologies.

What must be clear, is that there are no vehicles without any cybersecurity risk. There are no actions that completely eliminate all cybersecurity risks at the vehicle level. However, this does not mean that one is free to accept the risk if this risk is found unreasonable. Therefore one must:

Evaluate the risk of each system and the vehicle in total;
Define and implement mitigation actions in the areas where this risk was found unreasonable.

To implement these actions, it is necessary to execute a Cybersecurity Risk Assessment over any system using state-of-the-art methodologies. Currently, synch methodologies for Threat Analysis and Risk Assessment (TARA) in vehicle cybersecurity are defined by ISO/SAE 21434.

The Opportunities and Challenges of Upgrading Software in Vehicles

The possibilities that open up with updating the software are the following:

Dynamic improvement of product functions even after the sale of the vehicle. This is an important marketing advantage.
The ability to eliminate problems or errors found after production, including those affecting safety. It is important to note that even some HW problems are subject to correction, since in software-defined vehicles, HW flaws can be mitigated by modifying programme functions which in turn affect the behaviour of the vehicle’s HW devices.

As for the difficulties, the remote software update is definitely the most dangerous feature of the vehicle, since the impact of an error is enormous in every sense and can lead to the:

Mass failure of functions, including turning the vehicle into a bucket of bolts while moving.
Mass violation of Functional Safety.
Additional opportunity to violate Cyber Security.

All of the above can happen to tens of thousands of vehicles at the same time.

The trend towards software-defined vehicles manifests itself in every corner of the nowadays automotive industry, but as with any new technology, a clear, well-thought-out control of implemented innovations at all stages of their application is essential and inescapable.

Quality in Program and Project Management

Anton Rysin — Sat, 26 Aug 2023 23:20:45 +0000

Throughout the lifecycle of a project, from the very beginning to its introduction to the market, the most vital and perhaps the most challenging task for a manager is to maintain and evaluate the quality of handling things. As for a program manager, whose task is to supervise the whole cluster of projects, the quality of the management impacts the success of the project (and the company) in general.

Let’s take a closer look into the topic of the quality of Program and Project Management, explore its difference from product quality, and the ways to measure it without sacrificing other resources necessary for successful product implementation.

The Relationship Between Project Management Quality and Success Rates

In terms of the product, quality is a characteristic that determines a product’s proximity to the specification — the desired characteristics, features, and requirements for creating a product.

What is the quality of project or program management? The quality of project/program management is a value inversely proportional to the deviation of the actual state of the project’s target characteristics (scope, deadlines, spent resources) from the desired state of these characteristics.

The success of the project, in turn, is determined by the magnitude of the deviation from the original characteristics of the project. If the result of the project falls within the value of the permissible deviation from the initially established characteristics of the project, then the project is successful. Thus, the quality of project management determines the success of the project.

How to Incorporate Quality Control Measures in Project Management

It is necessary to ensure and measure the quality of project/program management throughout the entire lifecycle of the project. Sometimes quality can play a decisive role in the existence of the project altogether: with a low quality of project management during the lifecycle, there is a higher risk that further project execution is no longer possible.

To incorporate project/program management quality oversight, it is essential to formalize the characteristic of the deviation from the initial characteristics of the project. Having a designated way to measure the value of this characteristic, it is possible to compare the value with the maximum permissible parameters and develop the necessary action to bring the value of the characteristic closer to the target value. Here is a diagram depicting the described method:

As can be seen from the diagram, the greater the deviation of the actual state from the target, the lower the quality of project management. To improve the quality of management, the deviation has to be taken into account and provoke a mandatory reaction to itself, leading to a corrective action relevant to the deviation vector.

From this, we can deduce that creating a process that always allows for a predictable deviation from the initial characteristics of the project gives, in essence, the ability to obtain high-quality project management at the system level.

Quality vs. Speed: Striking a Balance in Program and Project Management

There is a common opinion claiming that quality is one of the sides of the quality-time-cost triangle, and that it cannot be achieved simultaneously with the other two characteristics. I am ready to challenge this, at least in terms of the quality of project/program management.

Investing resources in improving quality leads to significant cost savings across the project altogether, since the resources needed to mitigate the deviation far exceed the resources needed to ensure the quality of management. Furthermore, minimizing the deviation from the target state also leads to a reduction in time spent on the implementation. As a result, improving the quality of project management can lead (and usually does) to both a reduction in time and a decrease in the cost of the project. That brings us to the conclusion expressed earlier in the article: poor quality oversight can lead to the complete failure of the whole process. In fact, when the quality of project/program management is low, the scale of the consequences is boundless.

Deriving from everything discussed earlier, we have a conclusion discernible on the surface. Quality in both Program and Project Management is essential, and it is a great step on the way to successful results. It allows a deeper look into project dynamics, as well as prevents the excessive waste of resources or, in many cases, a total failure of the project in general.