Expert Perspectives: A Conversation with the Originator of UL 4600 on Safety, Security, and Autonomy in Automotive Development
Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.
Kenzie Ingram: Welcome to our Expert Perspective series, where we showcase insights from leading experts in complex product systems and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields. I’m Kenzie Ingram, your host, and today I’m excited to welcome Philip Koopman and Neil Stroud to our series.
Philip Koopman is a leading expert in embedded systems and autonomous vehicle safety, with a career spanning critical systems, embedded control networks, distributed embedded systems, and software safety. Neil Stroud is Jama Software’s own General Manager of Automotive and Semiconductor. He brings over 30 years of experience to the conversation, with the last 17 as an industry leader in the functional safety domain. Without further ado, I’d like to welcome Philip and Neil.
Neil Stroud: Hi everyone. I’m Neil Stroud, General Manager of our Automotive and Semiconductor business here at Jama Software. I’m honored today to be joined by Professor Philip Koopman. Phil, I’m going to hand over to you to do the introduction because you will do a way better job of it than I will.
Philip Koopman: Hi, I’m Phil Koopman and I’ve been doing self-driving car safety and embedded systems for a really long time. Self-driving car safety, like not quite 30 years, but we’re getting pretty close, and embedded systems for even longer. I’m a professor at Carnegie Mellon University, although I’m currently sort of finishing up that job. By the time this airs, I’ll be on my last sabbatical on my way to retirement from the university. That doesn’t mean I’m going to sit on the beach the rest of my life. It’s time for a personal pivot. And at Carnegie Mellon, I’ve been teaching embedded systems and doing a lot of work on automotive safety, software safety, but also a whole bunch of other different application domains. Just too many to list all over the place. So that’s kind of what I do for a living right now.
Stroud: Excellent. Thank you. And I’m really looking forward to this conversation. We’re going to go in many different directions and we’re going to talk about safety and autonomous vehicles and all kinds of things. Many folks will know you of course, as a very influential and critical voice around the world of autonomy and safety.
Koopman: I prefer not critical so much as advocating safety.
Stroud: Well, okay.
Koopman: If I’m critical, well, I’m just advocating safety. If people have a contrary view, you can decide what you think about that.
Stroud: Indeed, indeed. But before we get there, I’m interested to learn how you kind of got into all of this because if I think about it, I’ve been doing functional safety for 20 years, and I had no plans at all, it wasn’t even on my radar to get into this industry. I tripped and fell into it. It served me very well. So I’m interested to hear a little bit more about your story. How did you get here?
Koopman: To a degree, I tripped and fell into it too, but we have enough time, the longer story, it’s a really long story in details, but the longer story is back in high school I was in an organization called 4-H, which is for farm kids, and we had a farm, we had cows, but I lived in a city school district. So it’s sort of an interesting setup. And as part of it, for those from the US who are familiar with Boy Scouts, and I’m sure there’s a UK analog, there’s a thing called an Eagle Scout, which is sort of the pinnacle. Well, there’s a comparable thing in 4-H, a very parallel thing, although I point out 4-H is co-ed, and there’s some advantages to that, especially when you’re in high school and a teenager. But my thing thing was bicycle safety, it turned out.
And so I taught hundreds and hundreds of kids basic bicycle safety, which was sort of interesting. Now, I wasn’t planning on making a career of it. That’s just sort of part of how I fell into it. That was the angle that would get me to the end goal. So that was fine. That worked fine for me. Then I drove submarines for a living, and I wasn’t really the safety officer, but, well, actually I was the electrical safety officer, but that’s sort of like an incidental job. It’s more like if you’re going to sleep a couple dozen meters from a nuclear reactor every night, and there are other sources of nuclear radiation, which shall not be spoken of also around, you sort of take safety seriously. Oh yeah, and there’s this several-inch-thick steel hole, and if there’s a hole in it, all the water comes into the people tank, and that’s really bad for the people.
So safety’s kind of on your mind. It’s an extremely hazardous environment. And then I got the Navy, got a PhD, and eventually ended up at United Technologies, which has a bunch of embedded applications. Back then, they had not yet, right now, they sort of specialized, but back then they owned everything from elevators to car equipment to radars and sonars and jet engines and all sorts of stuff. And I did air conditioners and I did elevators. I touched a lot, everything, but I also did some automotive back then. Oh, yeah. Along the way, I was a chip designer of an automotive CPU, so I picked up some automotive experience there. And then I ended up at Carnegie Mellon University. So I was a chip designer. I did embedded applications at Carnegie Mellon and I was doing software robustness because DARPA gave us some funding for software robustness, which is kind of cool.
Koopman: It’s not really safety, but it’s reliability, dependability. Then, Carnegie Mellon ran a car across the US for a couple of 3,000 miles, 98% hands off the wheel. Self-steering car. They just used regular cruise control, but it was on a highway, so that was fine. But it was doing optical flow. I think it was a very primitive neural network, but it wasn’t neural networks like we know them today. It was basically an optical flow algorithm following the lines. And if there were no lines, it would follow the scratches in the pavement or the oil drips or the tire wear or whatever. And it was remarkably good. And if it’s raining, the pavement wear puts lines into the rain. It just figured it out. 98%. That last 2% was mostly off-ramps that have better lines than the road because they’re not as worn. So it loved to take off-ramps. And when it went underneath an overpass in bright sunlight, the auto contrast adaptation freaked out, and it just said, “I don’t know what’s going on,” because the camera flaked out.
And that was mostly the 2%. Because it’s interstate highways, it’s just not a lot going on for a single car making a single trip. And ever since, they’ve been working on that last 2% still today. But after that, there was a bigger thing called the Automated Highway Systems. And there was a consortium not run by NHTSA, run by Federal Highways to automate the highways. And Carnegie Mellon put a couple of city buses on a highway with that kind of technology and some of their cars driving around again, 98% %-ish. And they’re like, maybe safety should be a thing. And they had some funding, and I needed some funding, so I became their safety guy because I knew something about reliability, dependability. And that was in the mid-nineties.
That’s how I got into self-driving car safety. It’s like right place, right time, right opportunity. Back in the NavLog crew. And now this is, we’re talking 10 years before any of the grand challenge stuff happened. This completely separate effort way before grand Challenge. And there are a few of us, like one or two or three. No, there are at least two. I know at least one of them, there may be a third, who were doing safety back then, and that was about it. Right? There are not a lot. And so I got into self-driving car safety then, and it’s come and gone. And I’ve done a ton of other embedded things, hundreds of design reviews not on cars, but safety always just keeps popping up. Doing a design review on a flow control valve for a chemical plant. It kind of matters, right? Things go boom if that messes up.
So I’ve touched a whole bunch of safety standards, but it’s turned out that once self-driving cars got hot, well, there I was back into self-driving car safety.
2024 Predictions for Automotive Product, Systems, and Software Development
As the automotive landscape accelerates into 2024, we want to better understand and discuss what is driving change in the development of products, systems, and software, and how teams are evolving to address these complexities.
Jama Software® asked selected thought leaders — both internal Jama Software employees and our external partners — across various industries for the trends and events they foresee unfolding over the next year and beyond.
In part one of this six-part series, we asked the following industry experts to weigh in on the automotive product, systems, and software trends they are anticipating in the coming year:
We like to stay on top of trends in other industries as well. Read our predictions for Aerospace & Defense HERE, Industrial & Consumer Electronics (ICE) HERE, Medical Device & Life Sciences HERE, SoftTech HERE, and Product & Engineering Teams HERE.
2024 Predictions for Automotive Product, Systems, and Software Development
STEVE NEEMEH: Electrified power continues to be at the forefront of today’s automotive industry. Governments are driving this prioritization through regulation. For example:
Norway: The first in the world, aims to have 100% zero-emission cars by 2025.
Netherlands: 100% electric vehicle sales by 2030.
India: 30% electric mobility by 2030.
China: 20-25% of new car sales to be electric by 2025.
France: Ban on fossil fuel-powered vehicles by 2040.
UK: Ban on the sale of new petrol and diesel vehicles by 2030 and hybrids by 2035.
USA: California leads the way with executive order N-79-20 which sets a 2035 date for ZEV sales.
Germany: Ban on combustion engines by 2030
The mainstream acceptance of electric vehicles took a huge step over the last decade but will hit roadblocks along the way going forward, as the infrastructure, engineering tools and capability, supply chain, and consumer acceptance, slowly catch up with the dream of pure clean mobility.
The trends are moving towards software and software-enabled and defined vehicles. Although clean technology powers vehicles, software can make it a reality by overcoming some of these challenges. Connected vehicles, optimized power management, services on-demand, improvements in reliability and maintainability, and, of course, autonomy, are all powered by software.
CHRISTIAN SCHRADER: SDV – Software Defined Vehicle. The value perceived by the driver and the passengers today is largely driven by software: GPS, autonomy functions, virtual displays in the car including head up display (HUD), infotainment system, connectivity with mobile devices, cloud services, over-the-air updates. Also new value recognition (paid software services in the car/cloud).
Classic Autosar control applications will remain an ongoing topic for classical subsystems: steering, braking, headlamp control, battery etc.
JUDY CURRAN: As far as how the vehicle looks:
Lighting design continues to differentiate sports utility vehicles( SUVs) and trucks between original equipment manufacturers (OEMs.)
Potential move back to new car-like body styles after years of SUVs, cross-over utility vehicles (CUVs.) Aerodynamics are improved in cars, and cars are less expensive to help offset the cost of electric vehicles (EVs.)
Growth of smaller vehicles, and/or less contented vehicles as cars are becoming unaffordable; for example, less leather, more man-made leather likes. Less buttons; everything on the screen. However, there will still be a growing number of premium vehicles which will be highly contented. We will see many high price vehicles, and a drive toward a larger group of low-priced vehicles. The middle class is getting pushed out of the middle-priced vehicles. Most OEMS will want to win the business of the high price vehicles for obvious reasons.
Less vehicle refreshes; it is too expensive to do a minor facelift. Customers don’t expect these any longer. Components will be used for a longer number of years, and potentially across vehicles to save money.
As far as how the vehicle operates:
More EVs, but not 100% anytime soon. Not affordable… see biggest challenges.
More software driven features; again, cheaper to change only the software, not the hardware to offer a new feature like automated braking, or stop-go
Moreover, the air-software drops; OEMs able to solve quality issues with improved software releases, and charging customers for new features after the original sale of the vehicle.
Most valuable features for customers are assisted driving, or improved experiences. Less customer chatter about 0-60, hp, drive and handling, etc. — more about keeping customers safe and making their lives easier.
Autonomy continues to be quite a way out in the future; more ADAS features.
MATT MICKLE: One of the biggest shifts that we see is moving from internal combustion engines (ICE) to EV, we see this across the board largely due to regulations that back the production of electric vehicles. As the focus moves towards electrification, the significance of software becomes critical, and this changes the dynamic of how OEMs and large suppliers think about aspects of their business including the processes and tools that support them. The expertise required is extremely different and we see dramatic shifts in personnel to account for this.
The other obvious shift is with vehicle intelligence, which also relies heavily on software. More and more we move towards higher levels of autonomy faster than expected and automakers are needing to adapt quickly to keep up, leading to many dramatic changes. There are also many advancements related to this in regard to how mobility is achieved. With the rise of car sharing and mobility as a service, the need for the ability to update the vehicle on the fly and have modularity throughout the vehicle are essential to sustain the rapid increase in adoption and demand of these services. I’ve heard multiple people talk about how their children never plan to get licenses, it’s not even interesting to them.
STEVE RUSH: The software defined vehicle will continue to be a major trend in the next year. Feature development and new technologies will emerge as this trend becomes a reality.
Localization of mobility is another major trend. I’ll touch on this in the regulatory section.
Biggest Challenges – What are some of the biggest challenges you think Automotive companies will be working to overcome in 2024?
NEEMEH: From a business standpoint, electrified power continues to dominate the headlines, but the headlines have changed.
Leading automotive company has delayed $12B in EV spending and the message is that the consumer is unwilling to pay a premium for EVs.
GM-Honda scrapped a $5B plan to co-develop infrastructure around EVs.
Compounding the problem is the availability of money. Interest rates have been rising and are currently at the highest they have been in a generation. This makes capitalization difficult for startups, and the list of bankrupt startup EV companies is getting longer. Proterra, Lordstown, IndieEV, and WM Motors, are just a few examples. Availability of investment is going to impact technology development and limit the applicability of EVs. However, the business case is evolving and with international government support, it is by no means going away.
SCHRADER: Managing software complexity
CURRAN:
Profitability of electrified vehicles. Most are not profitable. Expensive new technology combined with the general affordability of new cars. Customers, especially younger customers, struggle to afford housing, and vehicles with higher interest rates.
Transitioning suppliers from ICE to EV components but keeping ICE strong. Making sure those suppliers that primarily profit from ICE remain profitable, and don’t go bankrupt on lower volumes. ICE can still make up 50% of the volume in the next decade, and we need the ICE suppliers to survive.
Hiring right skills; software skills, simulation skills
Labor cost; especially for the non-union plants now that they see the packages agreed by the United Auto Workers (UAW.) Potentially more unionization.
Too many companies in the business; too many OEMs now with all the new Chinese, and EV companies. The population is not growing at the same rate as the ability to produce cars. There will be consolidation. Too many suppliers of some commodities; for example, 80+ lidar suppliers. There will be consolidation.
MICKLE: Clearly automakers have faced many challenges with their supply chain in recent times whether it be from semiconductor shortages, lack of battery production facilities, geopolitical events, or world health crises. Some of these things still linger and will continue to cause a challenge in the industry, but additionally, I would say many of the same things that are driving advancement within the industry are requiring such a shift that they also present many challenges to overcome.
With a change to more of a software focus, there is an extreme shift in the expertise that is needed for the production of vehicles. Suppliers with a large focus in ICE are already starting to try and shift their business models with the eventuality of this disappearing almost completely. As so much focus is put on software, companies are scrambling to deal with prevention of cyber threats. Also, battery technology, infrastructure and production have to keep up with the exponential demand.
RUSH: Data. The software defined vehicle will present a number of challenges from a data perspective – connectivity and communication with the vehicle, storing and retrieving it efficiently and at scale. This is a major challenge. Traditional web technologies like REST APIs simply won’t meet the communication and connectivity need. New technologies will emerge to support connected vehicles.
Regulations – What changing regulatory guidelines do you anticipate having an impact on companies in 2024?
NEEMEH: The regulations promoting EVs that I mentioned before will not change in the short term. They will continue to drive innovation to overcome the challenges of modernizing our transportation networks.
A good example is the research being done at Purdue University to electrify the highways themselves so that charging can be done while the car is in motion. These kinds of breakthroughs would change the landscape and the paradigm by which we view vehicles. Today we see charging stations replacing gas stations with the limitation being the time it takes to charge. What if we didn’t need charging stations? The latest press release on the topic can be found here:
SCHRADER: Continued and increasing ISO 26262 demands in the wake of ADAS/AD functions. SOTIF for ADAS/AV. Also increased cybersecurity constraints (an insecure software in the car is a detriment to the SDV value recognition).
CURRAN:
Regulations will continue for customer safety; active/ADAS safety and passive/crash safety.
Regulations will continue for environment; fuel economy, percent EVs, zero carbon footprint.
MICKLE: I think the biggest challenges when it comes to regulation are mostly around policies that have been put in place to either accelerate the shift to EV or to take advantage of the safety benefits from AD and ADAS systems. For example, the Climate plan which has set a deadline for the sale of non-zero tailpipe emissions by 2035, or the Inflation Reduction Act to incentivize the transition to electric vehicles. This is causing major disruption as automakers have to adapt quickly.
Regulations themselves are adapting and rapidly being developed to ensure that safety and security are considered first and foremost. Also, standard bodies are working to harmonize in order to ensure that as complexity increases, the ability to maintain safety and security in development doesn’t become a tangled mess of jargon and specialized knowledge but is accessible. This is especially important as there are starting to be many more new players in the industry offering new technologies and causing the need for constant communication and integration.
RUSH: The regulatory space is quite murky when it comes to the future of mobility, and we are not likely to see broader regulatory alignment at the national or global level – it will be driven at the local level by municipalities and communities. Communities are demanding more transparency when it comes to safety concerns. I think partnerships between municipalities and mobility companies will deepen which will clarify the regulatory space.
Tool Innovation – From an Automotive engineering toolset perspective, what are some of the processes you think forward-thinking firms will be working to leverage or incorporate into their process and why?
NEEMEH:ASPICE 4.0 has just been released for review and adoption. Most notable are the changes to include hardware and machine learning in an attempt to adapt to the technologies that are impactful for automotive companies. This release and functional safety put a tremendous focus on the establishment of tools and processes as a part of an organization’s engineering development, release, and production process. Software is becoming the focus of development as a part of the movement towards software-defined vehicles, and the ALM tools are at the heart of the quality of these software systems.
SCHRADER: “Real” MBSE processes: Moving from separated “islands” to a more seamless end-to-end MBSE workflow. This is already of utmost importance and will continue to be like this beyond 2024.
CURRAN:
Using AI/ML techniques on the wealth of data that they have; help develop new products faster by being able to mine data for similar designs. This is especially important for suppliers who design the same part for tens of vehicles a year; examples — sensors, latches, antennae, etc.
Using simulation to validate designs instead of physical testing; this has been a goal for years and will continue to improve. There will never be zero testing, but definitely less testing and later in the program.
MICKLE: First, is that organizations need to find a way to keep track of all of the moving pieces, especially with regards to the integration of more and more software. Software and systems engineering teams traditionally work in very different ways and now will have to come together to handle the rapid change necessary for continuous development of software, while still adhering to the rigorous change management needed for compliance.
Additionally, organizations need to find ways to easily communicate with other players in their supply chain to adapt to the rapid pace of development — without dangerous gaps in impact from changes that may be made. It is essential that they need to find a way to not only communicate but understand the overall state across the supply chain.
RUSH: Configuration management will be the central shift from a process and tool capability standpoint. Configuration management, meaning the reuse of engineering assets across different variants and feature sets as well as branching from previous engineering work to kickstart new work. Many traditional automotive and semiconductor companies have been doing this for some time, but the burden of legacy tools with clunky and complicated user experiences will drive a shift toward more modern tooling.
Younger companies have matured to become multi-platform companies. This will drive configuration management needs at these younger companies.
What role will cybersecurity play in Automotive development in the coming year and beyond?
NEEMEH: Software-defined vehicles mean connected vehicles, which in turn means vulnerabilities. The UN treaty UNECE WP.29 defines a protocol to follow for compliance. Many countries have signed this treaty and full-blown implementation of the required cybersecurity management systems has begun with many OEMs. These cyber systems are essentially processes that are corollary to functional safety and require the right tools and processes to be implemented in the management of the software systems. This is another reason to focus on “how” you are developing your vehicle and not just what you are developing. The most difficult part to deal with in cybersecurity is the crossover between IT, Engineering, and Operations. There isn’t one owner. Therefore, orchestrating implementation requires cultural change within an organization.
SCHRADER: End customers take secure cars as a given. On the contrary a “proven insecure” car cannot survive in the market, and it will put shade on the entire brand (e.g. Jeep in the past). Cybersecurity is a foundation to build SDV upon, if you will.
CURRAN:
I think as software controls more of the safety features, it will be important that customers remain safe; no defects in the software or cyber-attacks of the software.
Keeping vehicles secure; too many cases of easily being able to start and steal a vehicle.
Data Ransomware can be costly, and will remain top of mind.
MICKLE: Cybersecurity is imperative. Software within vehicles will only take more and more of a central role and as a result, safety is tied to security more and more.
RUSH: The importance of cybersecurity and adherence to standards like ISO 21434 will be more important each year than it was the year prior. As new technologies emerge and the connected vehicle becomes more embedded in our lives, cybersecurity needs will be of the utmost importance to ensure adoption and build trust with consumers.
In your opinion, what are the biggest differences between Automotive companies that will survive to see 2030, and ones that don’t?
NEEMEH: As an engineer, I would love nothing more than to say technology. As a business leader, I know that the answer to this question is cash flow. The cost of money and the time value of money have both changed dramatically. Investment dollars are very hard to come by in our present environment.
SCHRADER: Those that understand software will survive. Those that understand mechanical engineering only will produce the car shells of the future, going from an OEM to a kind-of Tier 1 role. Or do you know who is actually manufacturing the case for an iPhone or a Samsung phone?
CURRAN: This hasn’t changed in years. Companies will survive if they can produce high quality, affordable, and innovative vehicles. It’s a three-legged stool. Innovative covers styling and features that the customer wants. If you don’t have these three, you will not survive. Quality is important, because as the second biggest expense in your life after a house, it better last. Affordability is obvious – if it is not affordable by enough people to make your company profitable, then you will not survive. Finally, your product needs to be desired.
MICKLE: The ability to keep up with the rapid pace of advancement of technology within the industry. There will be more changes that will be unexpected and the ability to swiftly understand the impact of those changes and adapt will be important. Also, more communication and collaboration with other players in the industry will help standards and best practices evolve with the pace of the technology.
RUSH: Automotive companies need to put their customers— drivers and passengers and the surrounding community alike — at the center of their development. There must be a higher purpose toward the future of mobility and the connected vehicle — one that puts safety and equity at the forefront of the mission. Feature development must go beyond simply monetizing the connected vehicle — it must make life easier and better for all of us. Automotive companies that miss this and focus on building flashy features or focus too much on monetization will miss out and likely won’t survive in the long term.
What advice would you give to new companies entering the Automotive industry?
NEEMEH: Develop an infrastructure to deliver high-quality software and provide a mechanism to scale delivery in an automated fashion. AI can speed up the development and delivery of software, and the right tools (like Jama Connect®) and equipment can automate the validation. That is the future. Don’t live in the past.
SCHRADER: Focus on new, valuable stuff: Autonomy, software, electrification
CURRAN:
Have a big bank account. It takes billions of dollars to get into this business; to build the plant, as well as to hire the engineers to design the car, and then the marketing/brand/warranty costs.
Make sure your strategy delivers quality, affordability, and innovation/desired to be owned.
If you are in the industry and on the edge to surviving, start to think about partnerships.
MICKLE: I would say to establish a holistic approach to keeping safety, security, and development in harmony rather than in isolation.
RUSH: Put the driver, passengers, and the community first when it comes to feature development.
What topic(s) do you wish companies were paying more attention to?
NEEMEH: Standards and regulations are evolving very quickly. A specification like ASPICE and ISO 26262 comes out and it implies a complete overhaul of engineering departments. It seems like an afterthought with many companies, but the implications are huge.
SCHRADER: Focus on software development: Different kinds of software, better tools and processes for these. Stuff that has been working well 15 years ago might not be state-of-the-art any more…
CURRAN:
Don’t forget the basics. New and old OEMs get enamored with EV, advanced driver assistance systems (ADAS), and SDV, but then make sloppy mistakes and have recalls on old technologies. Just looked at last week’s recalls, aluminum bolts loosening on a camshaft housing, connecting rod bearings, defective weld causing a water leak into electronics, driveshaft failures, interior materials have wrong level of fire retardant. And it is across the board, BMW, VW, Subaru, Honda, etc.
Simulation is great for the new technologies, but it could also really help improve the quality of the “traditional” components.
MICKLE: I would say cross training their safety, security, and development teams to ensure that there are not such differing objectives between them.
RUSH: Cybersecurity. Many companies have not yet developed or have underdeveloped procedures culture around this practice.
What is the biggest mistake you see companies in Automotive making right now?
NEEMEH: It is already clear that the EV world is going to face infrastructure issues, power delivery problems, supply chain constraints, and consumer adoption issues. Poorly predicting consumer behavior patterns, failing to anticipate the infrastructure and technology limitations, and adjusting the business model accordingly, are the mistakes I see most commonly. There is a model and a business case for EVs, but it’s not the only solution to all our energy and transportation problems.
SCHRADER: They act too slowly, backward looking
CURRAN: Hiring lots of new tech talent that are needed for software, EV, etc, but then offering buyouts to the previous team. I think it takes a mix of new tech experts with some traditional automotive engineering talent who understand the complexities of the vehicles and the manufacturing processes/variability. Recalls are up 80% this past decade over the previous decade. Vehicles are getting very complex; it takes a mix of software and hardware talent combined with more simulation tools. It is humanly not possible to validate these complex vehicles through traditional means.
MICKLE: Unwillingness to adapt to electrification or digitalization trends would be a major mistake, but also swinging too far to adjust all processes and teams to be working within a software focused method would be an overstep. Failing to recognize the need for the connection of cybersecurity and safety would also be a big disadvantage.
RUSH: Lax approach to systems engineering principles. Software and agile processes are deeply ingrained in the automotive and semiconductor industries. Younger software engineers learn these principles as they learn programming and they can conflict with systems engineering principles. Systems engineers may feel slower, but it will better address challenges of scale and safety considerations when it comes to development and verification.
What is the most innovative thing you’ve seen in Automotive this year that you anticipate other companies following suit in coming years?
NEEMEH: Using AI to solve labor constraints and the effective implementation of standards and regulations.
CURRAN:
Hard to pick one… but definitely great improvements in battery cost, and miles per charge. Improvements in time to charge. Great to see everyone jumping on the Tesla connector to help the infrastructure situation, etc.
Here are the ones that I’m most interested in. More and more safety-related features … we still have more traffic deaths every year, and even rising number of deaths. 42,000+ deaths in the US in 2021. That is a like 140 — 300 passenger planes crashing every year… just in the US. There used to be more large plane crashes, but not that many. The aerospace industry collaborated to really make air travel incredibly safe. We need to do more with ground vehicles. Automotive OEMs need to share more safety technology, and safety data and collaborate more together. Also, what new features can we create… Don’t start the car without a breathalyzer test? Number one cause of accidents in driving under the influence.
MICKLE: It may not seem sexy, but the AI to monitor parts of the driver’s body and eye positioning to send alerts to keep them focused and attentive is very innovative to me. It’s out of the box thinking like this in terms of safety which will allow for technology in Automation to progress successfully at the pace that is needed.
RUSH: Some of the new products and services coming out of Nxu (formerly Atlis Trucks) are really innovative and exciting. Specifically, Nxu One. While not strictly automotive, it’s automotive adjacent. I think it’s a great example of an innovative new product and program that can be monetized as well as puts the customer experience at the forefront. I’m interested to see where this goes.
Predictions – What do you think will remain the same in your industry throughout 2024?
NEEMEH: The adoption of EVs will continue, driven by government regulations. I don’t think that will change.
CURRAN: Same trends: EV, ADAS, SDV
MICKLE: The focus will remain on electrification and software, and it will only grow in the coming years.
RUSH: I think the software defined vehicle will continue to be the leading trend in automotive in 2024.
Do you think there will be any major disruptors in Automotive in the coming year? How do you think it will impact the industry?
NEEMEH: AI and the adoption of Software-Defined Vehicles will disrupt the supply chain and there will be winners and losers.
CURRAN: I don’t see any major disruptors other than how to use AI/ML techniques in the trends. The industry is trying to absorb the last five years of disruptions, which is more than the last 50 years’ worth. AI/ML — simulation will help.
MICKLE: I think that surprises that come will likely be from external factors due to government regulation, geopolitics, or other socio or economic disruptions.
Another possibility would be new discoveries in ecological and sustainable materials or advancements in technologies, a discovery here might have a dramatic effect on the industry.
RUSH: Nxu One. I think this is a win-win program for Nxu and customers.
Companies are trying to figure out how to monetize the future of mobility. I think you will see more startups in the charging station space – ushering in new ideas like public/private residential charging stations.
I think you may see more acquisitions of some of these disruptors. As some of the larger, traditional automotive companies look to buy over build when it comes to innovation.
What do you predict for regulation in the Automotive industry in 2024?
Will those trends still be prevalent five years from now? 10 years?
NEEMEH: 10 years from now the engineering departments will be far more efficient. Collaborative development tools and automation will be commonplace. Efficiency and AI will speed up the delivery of next-generation vehicles. AI will enable engineers to focus on the solutions, rather than the paperwork or manual labor. I also see a large push towards collaborative work environments that span the globe. Exciting times!
CURRAN: I truly believe affordability will be a growing trend, because wealth in the most recent generation is predicted to be more dire than previous generations. And I hope eliminating crashes will be a bigger trend. We can do more, people.
MICKLE: As complexity increases, regulation will increase, a big thing that will be interesting to see unfold is as autonomy increases, where the responsibility falls in the case of incidents.
RUSH: I think it will be another development and building year when it comes to the regulatory space. I think you will see increased acceptance and adoption of autonomous vehicles after recent major shutdowns in service. I think new attitudes of transparency will emerge between companies and municipalities and communities, paving the way for future regulations.
The software defined vehicle is not going away and we will see more and more resources put into this vision and new technologies emerging because of it. Regarding autonomous vehicles, each year will see increased adoption of autonomous vehicles and further clarity in the regulatory space. Frankly, many of these companies are craving clear regulations and standards so they have something to work toward.
In this blog, we recap sections from our eBook, “IEC 61508 Overview: The Complete Guide for Functional Safety in Industrial Manufacturing” – Click HERE to read the entire eBook.
Functional Safety Made Simple: A Guide to IEC 61508 for Manufacturing
What Is IEC 61508?
As discussed previously, industrial manufacturing firms need to prevent dangerous failures that may occur with the use of their system. The challenge is that oftentimes systems are incredibly complex with many interdependencies, making it difficult to fully identify every potential safety risk.
Systematic or random failure of hardware or software
Human error
Environmental interference, such as temperature, weather, and more
Loss of electrical supply or other system disturbance
Incorrect system specifications in hardware or software
IEC 61508 creates requirements to ensure that systems are designed, implemented, operated, and maintained at the safety level required to mitigate the most dangerous risks. The international standard is used by a wide range of manufacturers, system engineers, designers, and industrial companies, and others that are audited based on compliance. The standard applies to safety-critical products including electrical, electronic, and programmable-related systems.
Why Was IEC 61508 Developed?
The primary goal of the standard is human safety, and it’s based on a couple of principles, including:
Use of a safety lifecycle. The lifecycle outlines the best practices around identifying risks and mitigating potential design errors.
Probable failure exercises. This assumes that if a device does fail, a “fail-safe” plan is needed.
IEC 61508 applies to all industries; however, even though it covers a broad range of sectors, every industry has its own nuances. As a result, many have developed their own standards based on IEC 61508.
Industry-specific functional safety standards include ones for:
Industrial – IEC 61496-1, IEC 61131-6, ISO 13849, IEC 61800-5-2, ISO 13850, IEC 62061, IEC 62061, ISO 10218
Transportation – EN 5012x, ISO 26262, ISO 25119, ISO 15998
Buildings – EN/ 81/ EN 115
Medical devices – IEC 60601, IEC 62304
Household appliances – IEC 60335, IEC 60730
Energy systems and providers – IEC 62109, IEC 61513, IEC 50156, IEC 61511
The standard includes Safety Integrity Levels (SILs), which cover four stages from SIL 1 to SIL 4 and indicate whether a safety function is likely to result in a dangerous failure.
The IEC 61508 standard covers the most common hazards that could occur in the event of a failure. The goal of the standard is to mitigate or reduce failure risk to a specific tolerance level. The standard includes a lifecycle with 16 phases, broken into seven parts, including:
Part 1: General requirements
Part 2: Requirements for electric, electric programmable safety-relevant systems
Part 3: Software requirements
Part 4: Abbreviations and definitions
Part 5: Examples and methods to determine the appropriate safety integrity levels
Part 6: Guidelines on how to apply Part 2 and Part 3 Part 7: An overview of techniques and measures
The first three parts highlight the standard’s requirements, and the rest explain the guidelines and provide examples of development.
IEC 61508 Certification: Is it Required?
IEC 61508 certification is optional in most cases, unless you contract with a firm that requires it, or it’s required by your local government. Even if it’s not mandatory, achieving certification provides peace of mind and creates a clear path to improving safety. Certification is offered through international agencies specializing in IEC 61508, such as the TÜV SÜD. Completing certification provides creditability around your IEC 61508 compliance and is a point of differentiation if bidding on a contract against multiple contractors.
Understanding functional safety requires a hazard analysis and risk assessment of the equipment under control (EUC).
The hazard analysis identifies all possible hazards of a product, process, or application. This will determine the functional safety requirements to meet a particular safety standard.
A risk assessment is needed for every hazard that you identify. The risk assessment will evaluate the frequency and likelihood of that hazard occurring, as well as the potential consequences if it does happen.
The risk assessment determines the appropriate SIL level, and you can then use either qualitative or quantitative analysis to assess the risk. The guidelines don’t require a specific method of analysis, so use whatever method you prefer.
As we enter 2023, Jama Software® asked selected thought leaders – both internal Jama Software employees and our external partners – across various industries for the trends and events they foresee unfolding over the next year and beyond.
In the third part of our five-part series, we asked Beau-Colby Thomson – Associate Account Executive at Jama Software – Vlad Tanasescu – Global Industrial Sales Lead at Jama Software – and Steven Meadows – Principal Solutions Lead at Jama Software – to weigh in on Industrial and Consumer Electronics (ICE) product and systems development trends they’re anticipating in 2023.
2023 Predictions for Industrial and Consumer Electronics Product Development
What product, systems, and software development trends are you expecting to take shape in 2023 as it pertains to the ICE industry?
Beau-Colby Thomson: Industrial robotics and automation adoption will continue to grow at a rapid pace to combat labor shortages and growing product demand.
Industrial Internet of Things (IIoT) + edge computing use cases are growing year over year. This will introduce complex software development to product lines that historically may have been mostly hardware + firmware. The addition of a new discipline into product development organizations may result in disruptions to existing processes.
Energy Storage continues to be an area of focus for the world. As more utility infrastructures fail and the cost of renewable energy decreases, the demand for energy storage systems will grow.
Fusion/Fission/Nuclear is becoming more widely accepted (more so in Europe than in North America). The development of these products takes many years at a time to complete, however the headcount of the engineering organizations for these companies continues to grow now.
Steven Meadows: The Internet of Things (IoT) continues to become more prevalent across all industries. Everyday consumer electronics like laptops, home appliances, and tablets are manufactured with an increasing number of sensors and inputs that transfer data to different networks and applications. Improved remote monitoring of these systems can also be enabled through IoT helping customers to maintain their products with ease.
Cloud computing also continues to grow across the software industry. Cloud is becoming the golden standard allowing for more flexible, cheaper, and sustainable solutions. Companies increasingly rely on cloud computing for projects and daily activities, without the need for managing system administration, upgrades, and security.
DevOps is constantly evolving with more companies utilizing a unified software development approach, allowing for code to be delivered faster with improved quality. This means there is less time spent on the integration of teams, infrastructure management, and the deployment of code. Product managers continue to push for the implementation of DevOps, finding it critical to deliver their products at a lower cost, and with better quality outcomes.
Vlad Tanasescu:
Robotics: autonomous factories, warehouse and delivery robots, AgriRobots (agriculture), humanoids.
In terms of product and systems development, what do you think will remain the same over the next decade? What will change?
Thomson: The increasing level of connected products will drive more systems development maturity in organizations that fall under Industrial, Consumer Electronics, and Energy (ICE).
I believe over the next decade the struggle with writing ”good” requirements will not change.
Tanasescu:What will remain the same?
More software (SW) in systems, intelligence and autonomy in systems.
More autonomy.
Focus on smart / green energy (wind farms, etc.)
Innovation within roboticsand IoT.
What will change?
Functional Safety will become more important for industrial products.
New regulations will be introduced for robots as the technology evolves.
Meadows: Product development companies will continue to invest heavily in digital platforms which will help to streamline their processes, improve quality of their products, and improve team collaboration. Excel and Word are antiquated solutions that do not give product teams the necessary capabilities to handle complex development, so requirement solutions and Application Lifecycle Management (ALM) tools will continue to see an uptick in investment going forward.
There will continue to be an emphasis placed on functional safety with the functional safety devices market set to hit $10 billion by 2030. This means teams will need to prioritize functional safety throughout their development process to ensure that products are safe for industrial or private use. Development companies will continue to invest in the certification of their products, conforming to functional safety standards such as IEC 61508. This gives vendors and customers increased confidence in the overall quality of their manufactured systems.
How do you foresee regulations shifting in ICE product and Systems Development over the next decade?
Thomson: We will definitely see more safety regulations imposed as products are introduced to the real world and unforeseen risks occur. I believe these will be both safety and cybersecurity related regulations.
This is mostly for automated technologies and energy products, potentially cybersecurity for connected consumer tech or IIOT applications.
Tanasescu: More dedicated FuSa (functional safety) standard will appear for robots, IoT devices, and autonomous systems as these technologies become more embedded in society.
Requirements engineering, traceability, risk analysis will become increasingly important.
Any major disruptions to the ICE product and systems development industry you’re anticipating in 2023?
Thomson: The predicted recession may have an impact on consumer spending therefore consumer technology development. Companies may also be reducing funding to innovative R&D or incubation projects.
Tanasescu: I’m not sure about 2023, but I believe that over the next 10 years the robotics sector will grow exponentially.
Over the next years the traditional home appliance manufacturers will need to become IoT companies and focus on connected devices.
What sorts of process adjustments do you think development teams will need to make to be successful in 2023?
Thomson: Standardization & maturity.
Tanasescu: Work as agile as possible, even in regulated fields, while maintaining engineering rigor. Embrace a best-of-breed tooling approach. Enable collaboration across many global stakeholders.
What do you think will be some of the differentiators between a company surviving to see 2030, and those that do not?
Thomson: The ability to achieve executive initiatives to get products to market quicker while minimizing defects found after launch
Tanasescu: Investment in engineering. Understanding the value of structure and measurable product definition. Understanding of the future trends and the importance of software driven & connected devices, autonomous systems and digitalization.
Meadows: Development companies need to embrace a proactive approach to safety and quality when developing their systems. By incorporating functional safety throughout the product lifecycle, companies are much more likely to release safe and market leading products. These companies, and their customers, will experience greater long-term benefits than those companies that manage their safety and quality processes reactively.
By educating development teams on how to define requirements from the stakeholder level down to component, companies will have a better chance of building exactly what they intend to. By incorporating AI to help with requirements definition, teams can gain a competitive edge and author requirements in a concise and meaningful way.
What advice would you give to new companies entering the ICE industry?
Thomson: Build your house on bricks, not sticks. Leverage as much outside expertise/tools and focus your engineer’s efforts on innovation.
Tanasescu: Start with a structured, process driven approach when it comes to the use of development tools and traceability processes early on to best enable scale across the development programs, as the business will grow.
Meadows: When entering the industrial and consumers electronics industry, there are a lot of areas to consider when it comes to product development. Primarily, new companies should educate themselves on applicable standards and product development best practices. They should also consider certification in different areas including functional safety to make their products more marketable across a broader range of geographies and customer profiles.
What topic(s) do you wish companies were paying more attention to?
Thomson: It would be ideal if companies analyzed their engineering deficiencies and understood the amount of capital that gets wasted money in product development.
Tanasescu: Engineering predictability. Advantages of using a best –of-breed toolchain.
Where do you see Jama Software fitting in as the product development landscape evolves, and what can our customers expect as 2023 approaches?
Thomson: Hopefully as an integral part of the best of breed landscape. The biggest expectation we can point our customers towards is our ability to measure project health through traceability and requirement scores.
Tanasescu: Jama Software will continue accelerating the time to market efforts of ICE companies, make development more predictable and measure product development efficiency. Jama Connect® will keep enabling ICE innovators to succeed globally. I see Jama Connect as an expert in complex requirements engineering, traceability in systems engineering which serves its customers as a trusted innovation partner.
Our customers can expect continuous investment in and commitment to our product and ICE industry solutions.
Meadows: As systems become more complex with increased connectivity between interfaces and networks, the need for a best-in-breed product development platform that enables Live Traceability™ is critical. Gone are the days when teams could get by documenting requirements, tests, and risks in Excel and Word.
To speed time to market, produce better and safer products, teams need to adopt digital solutions, giving them a competitive advantage. Jama Software continues to invest heavily in its core platform, Jama Connect. We have been incorporating AI capabilities to improve requirements authoring, enhancing integration options with other best in breed applications and always bringing out new capabilities to support the development of some of the most complex devices on the market today.
In part 2 of our blog series, we cover the second half of our eBook, “A Guide to Road Vehicle Cybersecurity According to ISO 21434” – Click HERE for part 1.
Much like other automotive standards, ISO 21434 defines a system engineering V-model to be followed for the development of cybersecurity features.
Concept Development
The cybersecurity V-model starts with the definition of the exact “item” that will be developed. The item is a component or set of components that implement functionality at the vehicle level and is defined in an item definition. In many cases, the same item definition may be used for both functional safety analysis and cybersecurity analysis.
Once the item has been clearly defined, a Threat Analysis and Risk Assessment (TARA) is performed to identify what cybersecurity threats exist for the item and what the risk of those threats are. For threats where the risk must be reduced, concept level requirements are developed, known as cybersecurity goals. Cybersecurity goals form the highest-level requirements for the system being developed from a cybersecurity perspective. For risks that will remain after cybersecurity goals are achieved, cybersecurity claims are documented to explain what, if any, risks still exist and why they can be accepted.
After defining cybersecurity goals, a cybersecurity concept is created. This documents the high-level concept that will be used to achieve the cybersecurity goals. The concept takes the form of cybersecurity requirements as well as requirements on the operating environment.
Product Development
Once a cybersecurity concept has been developed, the system must be designed in a way that will satisfy the cybersecurity requirements. Any existing architecture must be updated to consider the cybersecurity requirements. Each component of the system should be designed to support the cybersecurity requirements.
Although ISO 21434 provides an example of developing a system in two layers of abstraction, no specific number of layers is required. Instead, the standard leaves it to the product development organization to define a process appropriate for the complexity of their system. This ensures that organizations can adapt the standard to a wide range of systems and, for many, means that their existing system engineering process will satisfy ISO 21434.
Once the components of the system have been designed and integrated, the system must be verified to ensure that it meets the cybersecurity requirements.
The methods for verifying the system can include:
Requirements-based testing
Interface testing
Resource usage evaluation
Verification of the control flow and data flow
Dynamic analysis
Static analysis
The integration and verification activities should be documented in a verification specification and the results of verification documented in a verification report.
Validation of Automotive Cybersecurity Goals
While the focus of verification is ensuring that the item meets the cybersecurity requirements, validation ensures that the item achieves the cybersecurity goals. This is done by first validating that the cybersecurity goals are adequate and then validating that the item achieves the cybersecurity goals. Validation may involve reviewing work products, performing penetration testing and reviewing all the managed risks previously identified. A rationale for the validation activities is required. The completed validation is documented in a validation report.
Even after product development is complete, the cybersecurity lifecycle continues.
Production
During the production phase, the item that has been developed is manufactured and assembled. A production control plan is required to ensure that cybersecurity requirements for post-development that were identified earlier in the lifecycle are applied to ensure that no vulnerabilities are introduced during production.
Operations and maintenance
Once an item has been integrated into a vehicle and the vehicle is on the road, new cybersecurity threats can still be identified. ISO 21434 requires organizations to have a plan for how to respond to this scenario.
Organizations must create a cybersecurity incident response plan each time a new cybersecurity incident occurs. This plan includes what remedial actions are required and how they will be performed. The response may range from providing new information to vehicle owners, to over-the-air updates, to recalls where the owner must bring the vehicle in for service.
End of cybersecurity support and decommissioning
Given that the cybersecurity lifecycle continues after vehicles have been sold to consumers, a method for ending cybersecurity support for those vehicles is needed. ISO 21434 focuses on developing a plan for communicating with customers when cybersecurity support ends. Since decommissioning can occur without the organization’s knowledge and in such a way that decommissioning procedures cannot be enforced, ISO 21434 only requires making documentation available to explain how to decommission the item with regards to cybersecurity, if this is even required.
Integrating the Automotive Cybersecurity with Overall System Engineering
ISO 21434 defines many cybersecurity-specific requirements and requires personnel with specific cybersecurity knowledge and skills. Because of this, it may be tempting for organizations to silo cybersecurity engineering activities from other engineering activities, but this would be a mistake. While risk analysis required by ISO 21434 can be considered as a separate activity from other system engineering activities, a single product still must be developed that meets a wide range of requirements, including cybersecurity requirements. For this reason, it is best to manage a unified database for requirements, architecture, and design, rather than tracking cybersecurity artifacts separate from others.
To support this, think of cybersecurity analysis as another input to product development, just like functional safety analysis and market analysis.
By taking a unified approach, a single system engineering V-model can be implemented that describes an overall product development process that incorporates cybersecurity without creating silos. While specialists will be focused on performing cybersecurity analysis, implementing known best practices and validating the final system achieves cybersecurity, this must be done in cooperation and coordination with the rest of product development.
How Jama Connect® Supports Cybersecurity Engineering
One way to implement a unified requirements, architecture, and design database is by using Jama Connect®. Jama Connect for Automotive provides a framework that incorporates the key requirements of ISO 21434 into a single project structure along with overall system engineering.
Specifically, Jama Connect for Automotive provides guidance on supporting the following activities:
TARA Cybersecurity goals
Cybersecurity concept
Design Integration and verification
Validation
An example of the framework is shown below:
Conclusion
ISO 21434 introduces a robust framework for organizations to apply the state-of-the-art in automotive cybersecurity to their product development. This framework is necessary from both a market and regulatory perspective. The high-level of connectivity available in vehicles today means that there many ways for someone to maliciously change a vehicle’s operation. While many consumers may be unaware of the risks today, if there are ever accidents that result from cyber-attacks, that will change quickly. A vehicle OEM’s brand will surely be impacted by such as incident. In addition, regulators have already imposed strong cybersecurity requirements in many regions. ISO 21434 is quickly becoming an essential regulation for companies developing products at all levels of the automotive supply chain.
Whether your team is young or seasoned, small, or large, all together or scattered across boundaries, Jama Connect for Automotive can help improve processes, reduce costs, improve time to market, and help achieve ASPICE compliance. To learn more about Jama Connect for Automotive, download our datasheet.
Interested in learning more about how Jama Connect for Automotive can help provide your team meet market demands more quickly and efficiently?
As the automotive industry becomes more complex and more connected, cybersecurity is emerging as a major concern, and therefore a priority for development teams.
One standard, in particular, has been developed to address cybersecurity risks in the design and development of car electronics — ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we cover:
An overview of ISO SAE 21434
The urgency behind automotive cybersecurity
How Jama Connect® supports cybersecurity engineering
Introduction
As the automotive industry becomes more complex, and more connected, cybersecurity is emerging as a major concern, and therefore priority, for development teams.
While vehicles have been traditionally isolated systems that had to be physically accessed to tamper with, increasingly, more and more vehicles include wireless connectivity. According to Juniper Research, the number of vehicles with wireless connectivity will rise from 110 million in 2020 to an excess of 200 million by 2025. These vehicles pose a much greater cybersecurity risk than previous designs.
One standard in particular has been developed to address cybersecurity risks in the design and development of car electronics – ISO SAE 21434 “Road vehicles — Cybersecurity Engineering.”
In this guide, we will examine this important automotive cybersecurity standard, how it is impacting automotive development, and lastly how Jama Software® can help.
What is Automotive Cybersecurity?
Cybersecurity, within the context of road vehicles, is the protection of automotive electronic systems, communication networks, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation.
What is ISO 21434?
Regarded as one of the most comprehensive approaches to connected vehicle cybersecurity, ISO 21434 specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance, and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.
This standard supports the implementation of a Cybersecurity Management System (CSMS).
The first edition of ISO 21434 was published in 2021 and automotive suppliers and OEMs should strongly consider integrating ISO 21434 into their current process.
What is a Cybersecurity Management System (CSMS)?
A Cybersecurity Management System is a systematic risk-based approach defining organizational rules and processes, security policies, resources, and responsibilities to manage risk associated with cyber threats to vehicle road users and protect them from cyber-attacks.
ISO 21434 provides vocabulary, objectives, requirements, and guidelines for cybersecurity engineering in the context of electrical and electronic systems within road vehicles. The goal of the standard is to enable the engineering of electrical and electronic systems to keep up with the state-of-the-art technology and evolving cybersecurity attack methods. Adhering to the standard will allow organizations to define cybersecurity policies and processes, develop a cybersecurity culture, and manage cybersecurity risk.
The structure of the standard is as follows:
14 clauses, 11 are normative
Similar structure and vocabulary as ISO 26262
Each clause has at least one requirement and one work product
Some clauses have RC (recommendations), and PC (permissions)
Nine informative appendixes
Terminology
To achieve the goal of a common vocabulary within cybersecurity engineering for road vehicles, ISO 21434 defines a number of terms.
Asset: A part of an item that has cybersecurity properties (ex: OBD II port, safety requirements)
Attack Path: A series of steps that an intruder could use to compromise an asset
Cybersecurity Goal: Top level product requirement resulting from the TARA (see below for TARA definition)
Cybersecurity Claim: An identified risk that will be accepted, typically mitigated by liability transfer
Cybersecurity Concept: Cybersecurity requirements on the item and operating environment that implement controls to protect against threats
Damage Scenario: The potential damage to a road user caused by the realization of a threat scenario
Item: A component or a set of components that implements a function at the vehicle level. Could be identical to the functional safety item
TARA: Threat and Risk Assessment. Assets with cybersecurity properties are identified and damage scenarios are identified if the asset is compromised. Threat scenarios are identified and supported with attack paths. Risk values are assigned, and cybersecurity goals are established for unacceptable risk
Threat Scenario: Potential cause of the compromise of the cybersecurity properties of one or more assets that leads to a damage scenario
Lifecycle
ISO 21434 defines a cybersecurity lifecycle that starts with the definition of a new vehicle system and ends with that vehicle system being decommissioned or support by the OEM ending.
This means that cybersecurity activities continue after a system is put into production to ensure that new vulnerabilities that are discovered after a system enters production are still identified and mitigations added if necessary.
ISO 21434 defines requirements for an entire organization developing automotive systems to ensure that the necessary cybersecurity governance and culture are in place to support cybersecurity engineering. This includes ensuring that the organization acknowledges that there are cybersecurity risks, executive management is committed to the management of the risks, and that the organization has defined rules and processes to implement the requirements of ISO 21434.
In addition, the organization must have personnel in cybersecurity roles that are competent, policies that define how information can be shared both internally and externally, an appropriate quality management system, management of all product development tools, and robust information security. Audits must be performed to ensure that the organization achieves the objectives.
Project-Specific
Each project that develops or updates a road vehicle system or component must manage the cybersecurity engineering activities specific to that project. This includes the following considerations:
a) Assigning the responsibilities regarding the project’s cybersecurity activities to specific individuals
b) Planning the cybersecurity activities that will be performed during the project
c) Creating a cybersecurity case that provides the argument for the cybersecurity of the system or component
d) Performing a cybersecurity assessment if the project risks deem it necessary
e) A decision of whether the system or component can be released for post-development from a cybersecurity perspective.
How EN 50128 Establishes Functional Safety Standards for Railway Software
In increasingly complex, rapidly evolving, and highly regulated industries, product development teams must build safety-critical products, while streamlining risk management and keeping accuracy and security at the forefront. This blog post will define functional safety and EN 50128 and explain why compliance with safety standards is critical to railway software and industrial manufacturing teams.
What is Functional Safety?
As part of the overall safety of a system or piece of equipment, functional safety is a key component that builds upon automatic protection. The best way to reduce risks in industrial manufacturing is to ensure automated protection systems have predictable responses to malfunctions or failures.
The concept of functional safety applies to everyday life and every industry you can think of. The International Electrotechnical Commission (IEC) provides this example of transportation functional safety:
“When you board a train, the subway or a cable car, functional safety ensures that the doors close before the vehicle departs and that they don’t open while it is in movement. They also ensure that the railway signaling system helps avoid that an oncoming train crosses your train’s path.”
When systems fail to operate, significant disasters can occur. Safety standards, such as EN 50128, are designed to reduce risk tolerance around these events.
What is EN 50128?
EN 50128 is a certification standard issued by CENELEC (the European Committee for Electrotechnical Standardization). The international version of this standard is IEC 62279. This standard specifies the requirements for railway applications, including communication, signaling, and processing systems for railway control and protection systems software.
According to Engineering360, the European standard “specifies the process and technical requirements for the development of software for programmable electronic systems for use in railway control and protection applications.” It aims toward any practical use where there are safety implications. This European Standard applies exclusively to software, the interaction between software and its system, and all safety-related software used in railway control and protection systems, including:
Application programming
Operating systems
Support tools
Firmware
Why compliance with safety standards such as EN 50128 is critical to railway software and industrial manufacturing teams
Eliminating all chances of risk may not always be possible. However, manufacturers must continuously seek strategies to mitigate potential safety issues, which is why industry experts in industrial manufacturing have created standards, such as EN 50128, and IEC 62279, to reduce risk and support the development of safety-sensitive products.
According to TUV SUD, “functional safety ensures that safety risks due to hazards caused by the mal-functional behavior of systems are reduced to an acceptable level. These safety risks are increasing in the rail industry as rail technology is becoming more and more complex, with both hardware and software interacting in different ways and components that are sourced from multiple markets.”
How Jama Connect® Can Help Organizations Achieve EN 50128 Compliance
Compliance is an essential goal for organizations in regulated industries, but it is not the only factor when delivering safe and reliable products to market. Organizations need defined processes for development and production and detailed end-to-end traceability to achieve compliance, from high-level user needs to validation and verification.
Jama Connect® is TÜV SÜD certified for developing safety-related products. Jama Software® is the first vendor that is both SaaS and Agile to receive the certification. In 2019, Jama Software completed additional certification as a software tool for railway applications according to EN 50128.
Focus and rigor in the product development lifecycle drives compliance as an outcome. While the ultimate responsibility of functional safety remains with the customer, Jama Connect eases the path to compliance so companies can focus on building products right.
Ensuring Compliance & Managing Risk with Jama Connect
Jama Connect is engineered to ensure quality with frameworks aligned to key industry standards which streamline design, development, testing, and risk management while maintaining compliance. Teams can quickly see the full historical context around a requirement when they contribute to a project — reducing the probability of errors as well as the time and overhead spent on risk analysis.
Like many industries, the semiconductor industry has seen a dramatic change over the past several decades. Simple, single function devices have evolved into complex multi-function devices with firmware, supporting software and, in some cases, full reference designs. While the products that the semiconductor industry sells are still integrated circuits (ICs), in many cases the supporting software, documentation and system-level understanding are just as important as the product themselves. A key example of this are the products produced for the automotive industry that must meet the Functional Safety requirements of ISO 26262.
Early in the days of integrated circuit design, companies generally focused on developing single function products. The development focus was on continuously optimizing for different applications and in many cases improving performance metrics like power, speed, and bandwidth. Later came an increased focus on reducing product size and cost. The common thinking was that if team could build a product with better performance metrics than the previous generation, there would be a market for the product. For these teams the skill of circuit design and the capabilities of manufacturing were the ultimate competitive advantage. A great deal of system-level understanding is not required, although many teams had Applications Engineers with an understanding of the various applications their products would be used for.
For many companies in the semiconductor industry, circuit design and manufacturing are still competitive advantages. For others, an increased focus on integration has encouraged them to think in terms of providing a complete solution, rather than just products. Increasing levels of integration is often driven by a goal to decrease size and cost of the solution but doing so requires a better understanding of the end application and more systems-level thinking in developing the solution. This understanding of the end application leads to a focus on clearly understanding and communicating the requirements to ensure successful product development. While in single function products the requirements are often simple and the circuit design is the challenge, in more complex products the requirements can become quite complex and truly understanding the need is just as critical as executing on developing a solution.
No aspect of integrated circuit development increased functional complexity as much as adding firmware and software to the overall solution being provided. While adding software and firmware to a solution is often done to solve a specific problem, it quickly opens up such a wide range of functional possibilities that the complexity grows rapidly. While there are still teams focused on advancing the state of the art of circuit design, just as many (maybe more) teams are developing full solutions with a semiconductor element as well as firmware, software and even system integration. The ultimate representation of this trend is semiconductor companies providing complete reference designs that contain nearly all the engineering required to produce an end-product.
In the automotive industry, the trend of providing a complete system-level solution has not been as strong as in other industries like IoT or consumer, but another trend has emerged: providing a safe solution. Integrated circuits sold into automotive applications have long had to achieve some of the toughest reliability standards. Now it is increasingly common for vehicle electronics to impact the safety of the vehicle, so not just reliability is required, but also functional safety. Achieving functional safety requires a lot more than circuit design and process technology. It requires understanding of how failures in an integrated circuit can impact the system. It requires robust development processes not traditionally employed in the semiconductor industry.
Nowhere was the need for this more strongly articulated than at the “Guidance & Application of ISO 26262 to Semiconductors” conference held virtually in August 2021. In the first session of the conference, several automotive OEMs joined forces to explain how important it is for semiconductor suppliers to develop pre-integrated, pre-certified and pre-tested solutions that meet the requirements of ISO 26262 and place the minimum burden on system integrators to integrate the solution into their system and safety case. Functional Safety adds a lot of overhead to vehicle development and receiving complete solutions from their suppliers goes a long way toward reducing that burden.
While many semiconductor suppliers have been playing catch up to meet the requirements of ISO 26262, others are turning it into a competitive advantage. These suppliers are winning business on the strength of their functional safety competency. They have developed robust processes featuring robust requirements management, configuration management and safety analysis. As a result, they can provide their customers complete safety cases that save their customers significant time when integrating their solutions. Some are even furthering the state of the art in functional safety by participating in standards development. It is common for multiple suppliers to have technically equivalent products, so in these cases safety competence can become the deciding factor in which semiconductor solution an OEM or Tier 1 supplier ultimately selects.
With the automotive industry working toward fully autonomous vehicles, the importance of developing safe products is more critical than ever. It will take the whole industry working together to furthering the state of the art in all areas to achieve the goal of full autonomy. That state of the art includes both skillful circuit design and robust process that ensure safety.
Never has there been a time where it was more critical for the semiconductor industry to adopt new skills. Circuit design and manufacturing will always be the core competency of semiconductor companies, but for those focused on the automotive industry safety, it is increasingly necessary for safety to be a core competency. Developing this as a core competency can lead to increased market share in today’s exciting automotive market.
This post on functional safety for autonomous driving is Part III in our three-part series with automotive expert Patrick Freytag. If you haven’t already, please go back and read Part I, which talks about how the automotive sector is changing – and Part II, which discusses ways to address functional safety.
Since functional safety has a product lifecycle approach, it has a wide impact on all processes in a company. As a newcomer to functional safety, it’s challenging to focus on the most important aspects, especially for new entrants in the knowledge-intensive automotive sector. Here are best practices based on my observations and experience.
Functional Safety for Autonomous Driving – Best Practices for New Market Entrants
Executive Management Team: Pay Attention to Functional Safety
Product safety should be at topic of conversation for the Executive Management Team (EMT) because of the legal responsibilities placed upon the company by deploying a vehicle to customers. The EMT should understand that it needs dedicated resources to achieve product safety. One of the most important tasks of the EMT is to implement a Safety Engineering Management and to assure that roles and responsibilities for quality and safety are defined and communicated in the company. Members of the safety team need a specific skill set, so it is important to invest in functional safety education and qualification. It is important to foster a quality and safety culture in the company. For that reason, quality and safety should be part of goal agreement and performance evaluation. Quality and safety have to be recognized as a core responsibility and a performance indicator for employees.
Project Management: Plan and Track Functional Safety
Project management has to incorporate functional safety in the product concept and development plan. The Project Manager (PM) should consider the additional time and cost in the project plan and the project budget. Product development plans must include quality and safety milestones and the related work products. What should be done if the PM doesn’t receive proof that quality and safety milestones are reached at the gate reviews, for example? Well, that’s for sure a red flag. Situations like these may point to deeper rooted issues, and should not be brushed under the rug. The PM should start a GAP analysis and request an action plan. I recommend escalating the issue to the executive team ASAP in case there is missing proof of product safety. It won’t get better without commitment and planned actions, the longer you wait the worse the situation will get. Since safety considerations most typically permeate several layers of system design, it is not an attribute that can be tagged on shortly before the start of production, it has to be implemented from the beginning.
Development & Functional Safety Team: Implement and Validate Functional Safety
Industry experience shows that functional safety is not a topic you can assign to one responsible person. For example, a technical safety concept is created by a team of software, hardware, and system-level experts and moderated by a systems architect in collaboration with functional safety engineers. This means that the functional safety manager is a role that is played a few times in a company, while the role of a safety engineer can be assigned to even an entire team. As mentioned, functional safety requires specific domain knowledge and safety engineering expertise. But what can be done if this expertise is missing in-house? My recommendation is to compensate it with external resources as an interim solution. Start functional safety education and qualification as a long-term solution. Safety must be addressed in product development with adequate engineering methods and domain knowledge to define safety requirements. These safety requirements have to be implemented, tracked, managed, verified, and validated to make sure that risk reduction is realized, and the product is safe.
The Evolution of Functional Safety for Autonomous Driving
The functional safety focus is on avoiding and mitigating failures in E/E systems. That also works well for Advanced Driver Assistance Systems (ADAS). When a failure is detected, the driver gets alerted, and mitigation measures are performed to reach a safe state. These systems are called fail-safe. Let’s take Adaptive Cruise Control (ACC) as an example. When a failure is detected, a warning will be displayed in the Instrument Cluster. This visual warning is typically combined with an acoustical warning to get the attention of the driver. The ACC function will be switched off, and the driver is in charge to control the vehicle’s speed and keep a safe distance again.
Additional Safety Considerations for Autonomous Driving
The ADAS safety mechanism described above will not be sufficient for a fully autonomous vehicle. It’s not possible to switch off the automated driving system because there is no driver in the loop to take over. An Autonomous Vehicle (AV) has to work under all (failure) conditions, it has to be fail-operational. An AV without a driver in the loop also needs situational awareness, understand the surrounding world, decide, and act. This situational awareness is created by data fusion from a variety of complex sensor systems based on lidars, cameras, and radars. The combined data is then interpreted to plan and take action. This interpretation and planning are achieved by complex algorithms, driven by Artificial Intelligence (AI) and Machine Learning (ML).
Today, many connected and ADAS-equipped cars are already available. Connectivity features and information sharing are increasingly used for updating vehicle features, maintenance-related diagnostics, and traffic services. This development will also increase the attractiveness of an attack on vehicles by hackers with different motivations and it introduces additional risks for vehicle cybersecurity.
Safety Concerns Due to System Limitations and Misuse
What happens if an automated driving system has no system failure but doesn’t work as intended? Unsafe behavior could be triggered by limitations in the sensor systems, extreme conditions, or unforeseen situations. In addition, misuse could confuse the AI algorithms and result in unsafe behavior too.
An example of misuse of an ADAS was showed by Consumer Reports. Consumer Reports reported in April 2021 that it was able to trick a Tesla into driving in autopilot mode with no one at the wheel. Real-life proof followed in May – Police arrested Tesla driver for operating his car from the back seat while traveling on a San Francisco Bay Area freeway. The officer confirmed the sole occupant was in the backseat, so he took action to stop the car and saw the occupant move to the driver’s seat before the car stopped. In response, Tesla activated the cabin camera with a software update to detect and alert driver inattentiveness while autopilot is engaged for Model 3 and Model Y end of May.
Here a typical example of limitations, an AV is driving and confronted with black ice conditions. While an experienced driver should be able to comprehend the situation and respond properly, an AI-based AV might not. Without sensing the icy road condition, an AV might drive faster than is safe for the condition.
As a result, there has to be an addition to functional safety considering safety violations that occur in absence of a system failure.
Safety of Intended Functionality or SOTIF (ISO/PAS 21448)
The publicly available specification ISO/PAS 21448, titled “Road vehicles — Safety of the intended functionality” was published in 2019. SOTIF is defined in the standard as: “The absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable misuse by persons.” The goal of SOTIF is to avoid situations where vehicles are working as designed, but are failing under real-world scenarios. ISO 21448 provides guidance on the design, verification, and validation measures to achieve the SOTIF. The current version covers Advanced Driver Assistance Systems (SAE J3016 L1 and L2). It can be considered for higher levels of automation; however, additional measures will be necessary.
The Standard for the Evaluation of Autonomous Products (ANSI/UL 4600)
The UL 4600 standard was issued in April 2020 with the scope of the Safety Evaluation of fully Autonomous Driving Systems that operate without human intervention. The goal of UL 4600 is to ensure that a comprehensive safety case is created, including safety goals, argumentation, and evidence. UL 4600 covers the safety principles, risk mitigation, tools, techniques, and life-cycle processes for building and evaluating a safety argument for vehicles that can operate in an autonomous mode without human supervision. Therefore, the ML-based system aspects of the autonomous operation are covered. UL 4600 works well with existing automotive safety standards such as ISO 26262 and ISO/PAS 21448 by building on their strengths while also filling their autonomy-specific gaps.
Conclusion
The safety challenge for autonomous vehicles can’t be addressed with a single standard as of today. As we move on from existing Advanced Driver Assistance (L1 and L2+) to fully Automated Driving Systems (L5) the standards and methods will evolve too.
Current state-of-the-art automotive safety is achieved with a combination of different engineering methods and processes:
Functional Safety (ISO 26262)
Guards the E/E malfunction behavior due to systematic and random hardware failures for vehicles with a human driver present responsible for safe operation
Safety of the Intended Functionality (ISO/PAS 21448)
Deals with the functional limitation regarding the absence of unreasonable risk due to hazards resulting from functional insufficiency of the intended functionality or reasonably foreseeable misuse by persons. SOTIF covers L1 & L2 ADAS vehicles with a human driver present responsible for safe operation.
Cybersecurity engineering (ISO/SAE 21434)
Protects road vehicle systems and components from harmful attacks, unauthorized access, damage, or anything else that could interfere and compromise safety functions
Evaluation of Autonomous Products (ANSI/UL4600)
Proofs the safety of fully autonomous road vehicles that can operate without human supervision
Take Away:The combination of different engineering methods is needed on the way to fully Autonomous Driving
Functional Safety helps you to do things right
Safety of Intended Functionality helps you to do the right things
Cybersecurity helps to protect the safety functions from being compromised
Evaluation of Autonomous Products helps you to provide proof that you did enough safety engineering work to achieve a safe autonomous product
This blog post concludes the 3-blog miniseries on automotive insights and best practices on the way to autonomous driving. Special thanks to Jama Software for the opportunity to share my observations and experience with you. I hope you enjoyed reading my thoughts and got useful insights into the complex and interesting world of automotive safety and autonomous driving.
My last blog post covered why and how the automotive sector is changing fast over the last few years – you can find that post here. A common expectation is that our future cars will be connected, automated, shared, and electric. In a current Motional Consumer Mobility report, Americans were asked what is their most important consideration to use a self-driving vehicle. Nearly two-thirds of Americans (65 percent) say safety is the most important consideration when deciding to use a self-driving vehicle. So let’s take a closer look at automotive functional safety and how to deliver a safe product.
Safety Considerations for Product Design
Modern cars are a complex piece of technology. They are connected, have sophisticated Infotainment Systems (IVI) and Advanced Driver Assistance Systems (ADAS). You will be surprised about the amount of software used in the 30 to 70 electronic control units in a car. There are up to 100 million lines of code deployed in a modern high-end car today. System complexity will increase even more when we move beyond ADAS-supported driving to Automated Driving Systems (ADSs) in the future.
The challenge for the industry is that new potential hazards may arise with the increasing use of electronics and software in cars. Apart from complex technology and consumers’ expectations, we will get regulations covering the safety of future cars. In the U.S., this is the responsibility of the National Highway Traffic Safety Administration (NHTSA).
Defined by the Vehicle Safety Act in 1966, the NHTSA has the sole authority to make final decisions on rules and safety standards for future road vehicles. Once the NHTSA establishes a standard, the Agency is required to ensure that manufacturers comply when producing new vehicles.
In 2016 the NHTSA published “Vision for Safety,” a non-regulatory approach to automated vehicle technology safety. “Entities are encouraged to follow a robust design and validation process based on a systems-engineering approach to design ADSs free of unreasonable safety risks. The overall process should adopt and follow industry standards, such as the functional safety process standard for road vehicles…”
Which industry standard is the NHTSA referring to?
The mentioned standard is the ISO 26262 standard. First issued by International Organization for Standardization (ISO) in 2011 and later updated in 2018. The ISO 26262 is titled “Road vehicles – functional safety,” the first comprehensive voluntary industry standard for safety engineering of Electrical and Electronic Systems (E/E) in road vehicles. This standard recognizes that safety is a system attribute and can be addressed using systems engineering methods. ISO 26262 emphasizes the importance of implementing a safety engineering management and fostering a safety culture.
What is functional safety and how to comply?
Functional safety is defined as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems.” The goal of ISO 26262 is to ensure safety from the earliest concept to the point when the vehicle is retired. To ensure vehicle safety, the standard outlines an automotive safety life cycle that describes the entire production life cycle.
Specific steps are required in each phase of the safety life cycle. One of the most important steps at the beginning of the safety life cycle is the Hazard & Risk Analysis of potential hazards (HARA). The result is an Automotive Safety Integrity Level (ASIL) classification of the hazard and the formulation of an overall safety goal. Safety goals are basically the level of safety required by a system or component to function without posing any threats to the vehicle.
An ASIL is assigned by evaluating three risk parameters, severity, exposure, and controllability. Severity defines the consequences to the life of people due to the failure that may occur.Exposure is the likelihood of the conditions under which a particular failure would result in a safety hazard.Controllability determines the extent to which the driver will be able to control the vehicle should a safety goal be breached due to the failure or malfunctioning. An ISO 26262 method provides guidance on how to assign the ASIL for a hazard once severity, exposure, and controllability are determined.
In the next step, a functional safety concept is developed for each safety goal. The functional safety concept defines functional safety requirements within the context of the vehicle architecture, including fault detection and failure mitigation mechanisms, to satisfy the safety goals. Then the technical safety concept is developed to specify the technical safety requirements within the system architecture. The technical safety concept is the basis for deriving the hardware and software safety requirements that are used for developing the product. These safety requirements have to be traced, managed and validated through product development to assure the delivery of a safe product.
Functional Safety describes a risk-based system engineering approach to avoid unreasonable risk. From a business aspect, using ISO 26262 as a guideline helps you to avoid costly product recalls due to safety hazards. Tesla recalled roughly 135,000 Model S and Model X vehicles over Touch-Screen failures in February 2021. The move came after the National Highway Traffic Safety Administration requested a safety recall. NHTSA asked for the recall because the center display in some models can fail when a memory chip runs out of storage capacity, affecting safety functions such as windshield defogging and defrosting controls, exterior turn signal lighting, and rearview backup camera display.
Following the standard minimizes the risk of harm to people and non-acceptance of your products by the market. In particular, automobile manufacturers have a legal responsibility to design their vehicles to guarantee driver, passenger, and pedestrian safety. As a consequence, automobile manufacturers can be named as defendants in a product liability suit. For example, Toyota Motors agreed to pay $1.2 billion to settle the Justice Department’s criminal investigation into whether the company hid safety defects related to unintended acceleration in 2014.
Takeaway
Functional safety is an essential part of product development and needs to be addressed early in the concept phase and considered through the full product life-cycle. ISO 26262 offers an engineering guideline and methods to avoid or at least mitigate systematic failures and random hardware failures of Electrical and Electronic Systems. The derived functional safety requirements have to be implemented at the lowest level up to the system level, both from a hardware and software perspective. This offers the ability to prove that the added E/E-systems are free of unreasonable safety risks.
The pragmatic engineering approach is to use existing knowledge, or how I call it, to use the industry’s memory. You should look at the ISO 26262 series as the framework, and set of guidelines and methods. ISO 26262 can help you with system engineering methods for a safe product and still give you some flexibility in the development process. This is especially helpful for newcomers to the automotive industry, who may lack specific automotive safety engineering experience.
Let’s put it that way, using existing engineering methods and knowledge is like standing on the shoulders of a giant – you can see further. This is even more true for automotive product safety because there is no room for trial and error.
Stay tuned: The next blog post in this series will give real-life advice on how to implement functional safety in your organization and products, and a glance at the evolution of functional safety for autonomous driving.
My last blog post covered why and how the automotive sector is changing fast over the last few years –