This blog previews our recent webinar. To watch the entire presentation, visit: “Breaking Through Organizational Inertia and Driving Adoption”

Breaking Through Organizational Inertia and Driving Adoption

Change is hard. Even the most advanced semiconductor organizations struggle to adopt new processes and tools. Resistance doesn’t result from bad intentions; instead, it arises from organizational inertia: entrenched cultures, siloed teams, and the very human tendency to stick with what’s familiar.

In this practical discussion, we explore how engineering teams are overcoming these challenges. Steve Rush, Principal Solutions Lead at Jama Software, shares proven approaches to reduce resistance, align teams, and drive lasting adoption of new processes.

What You’ll Learn:

• Identify what organizational inertia looks like in practice and how to address it
• Reframe conversations with resistant teams and stakeholders to foster alignment
• Practical strategies for driving requirements management adoption and ensuring long-term success
• Build momentum for change in complex semiconductor environments

If your organization is struggling to turn process change into real adoption, this session will share actionable ways to create traction where it matters most.

WEBINAR PREVIEW – WATCH ENTIRE PRESENTATION HERE

TRANSCRIPT BELOW

Steve Rush: Thanks so much, Juliet. I really appreciate that introduction. Well, hello everyone. My name is Steve Rush, and as Juliet said, I’m a principal solutions consultant here at Jama Software. And I’m genuinely excited to dig into this topic with you today. It’s one that’s close to my heart, and I think it’s something that everyone in our industry has run into at some point. Here’s what we’re going to cover. We’ll open up and frame the issue of organizational inertia. We’ll diagnose the inertia and profile the forms of it that may feel very familiar to you. We’ll talk about how to reframe the conversation with resistant teams. We’ll get into what actually works when it comes to driving adoption, and we’ll close with some questions from the audience.

Let’s get into it. First, let’s start with something I think we can all agree on. Change is hard. Even the most advanced engineering organizations in the world struggle with this, not because of bad intentions, but because of organizational inertia. That is a fact. Change agents trying to deliver better business outcomes, whether it’s digital transformation or getting ready for the era of AI, can feel like they’re steering ships through rough waters, and that’s because they are. Here at Jama Software, we work with some of the largest companies in the world, organizations with a huge collective history. Their tools, processes, systems, and people are deeply entrenched. Change can be volatile, turbulent, or just painfully slow. But here’s the good news. Adoption doesn’t have to be. Let’s unpack this together.

So what does organizational inertia actually look like? I chose this word inertia intentionally. I could have called this webinar overcoming organizational resistance, but I think that word, resistance, is confrontational right out of the gate, and I think it puts people on the defensive before the conversation even starts. I think inertia is a better term because this type of resistance or inertia can be passive or active. Institutional resistance is a form of active inertia. Organizational silos are a form of passive inertia, and I think the word is more precise here and more useful in our context. I think naming the inertia and understanding it serve you in two important ways.

First, it helps the change agent find the right solution. Not every approach fits every situation. Understanding which form of inertia you’re dealing with, whether that’s passive avoidance, hard personalities, institutional friction, or silos, helps you choose the right response rather than applying a one-size-fits-all solution. Second, it helps you communicate credibly to the people responsible for your success. Change agents can’t go it alone. You need support. The way you earn that support is by articulating the obstacles clearly, building a shared understanding of what you’re up against and what it will take to move through it.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Rush: Here are three forms of inertia that will probably feel familiar. Let’s walk through each one. First, institutional resistance. Teams have established workflows, tools, and norms, and any new tool or workflow can threaten the comfort of the familiar, even if the familiar may be efficient in that individual team’s context. The problem is that a familiar individual process or tool is siloed off and not integrated into a larger system context, causing issues with collaboration, problems with traceability, and re-usability. The flags here to watch out for are people saying things like this. “This new tool you want me to learn is too hard, or this new process is slowing us down, or the classic, why are we being forced to do this?” And to be fair, that last one contains a legitimate question underneath it. People want to understand why. Institutional resistance isn’t always loud. Passive avoidance, like quietly working around a new tool or falling back to legacy processes and homegrown spreadsheets, is a form of resistance as well. It’s one that’s easy to miss if you’re not looking for it.

Next, siloed teams. Teams are not working in a single source of truth, or not working in a common enough model. Requirements in this case can look different to the hardware engineer, the software engineer, and the systems engineer. And when teams operate in separate tools, with separate workflows and siloed off processes, they’re often solving the same problems in parallel, completely unaware of each other. The flags with this one tend to surface later, late-stage changes, missed approvals, finger-pointing at stage gates, and products that consistently miss launch dates, with everyone having a different explanation as to why. That is the silo talking.

These teams also miss the opportunity to learn from one another. A tool or process is being designed in isolation from the very groups that sit upstream and downstream that depend on their work. Personality-driven pushback. One skeptical voice can stall adoption across an entire team. Individuals drive organizational change for better or worse. And the loudest voice in the room isn’t always the wisest. The flags here to watch out for are lack of participation, unconstructive criticism, and skepticism without any rationale. Listen for this specifically. If someone says no without a reason, that’s a flag. No, and here’s why: it’s a conversation. No, just by itself is a wall. Here are a few patterns and sample feedback you’ll recognize when pushing a new tool like Jama Connect. We already track that in a spreadsheet. This is a software team problem, not ours. We don’t have time to learn a new tool right now. Our process works fine. It’s always worked. Can we map these patterns to the forms of inertia we just saw?

Here’s how I would map it back to the previous slide. I think this understanding is key, so we know how to respond and implement the right solutions, how to give support when we need more discovery, when we push back, and when we escalate. Now, the forms of inertia I’ve already outlined are broad, and I bet they’re familiar to everyone that’s listening in on this webinar, but I want to segue a bit and talk about the semiconductor industry specifically because I think they have a couple of unique challenges, but I hope that resonates across industries as well, and you pick something up. First, no unified data model.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Rush: There is no one-size-fits-all data model for the semiconductor industry. The context in which the chips are utilized often drives much of the development. A chip going into a car might require a safety element out of context model. A chip going into a rocket might need to meet the objectives of DO-178C. A lab-on-a-chip project will need to adhere to certain medical standards. Oftentimes, these companies need to develop the data model from scratch, and that effort in and of itself is just a daunting task, so they choose not to do it because it’s too time-consuming and too difficult, and they only adopt a requirements management tool like Jama Connect if they’re forced to.

But we know there are studies suggesting that improved requirements and using a dedicated requirements management tool like Jama Connect reduce late-stage changes and defects and improve productivity. So it’s really in the company’s interest to adopt a tool like this. This is also where I think Jama Connect and our new semiconductor solution can help because it’s tailored for common semiconductor use cases. You can start using the tool right away for automotive manufacturing and shift design. It’s also very flexible, so you can configure it differently for different use cases very shortly after your Jama Connect purchase.

Too much functional safety focus. Functional safety tends to own the very first implementations of a tool like Jama Connect, which makes sense because good requirements management practices and processes are mandated in standards like ISO 26262 and DO-178C. So companies go out, and they purchase a requirements management tool if they’re mandated to meet the objectives of those standards, but they struggle to roll it out beyond those functional safety use cases, despite the fact that they have problems with traceability and collaboration, which the requirements management tool can help solve. So a functional safety bias may exist, which holds the tool back from expanding more broadly across teams and organizations, and those teams just end up not taking full advantage of the tool. Familiar wins the day.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
Breaking Through Organizational Inertia and Driving Adoption

The post [Webinar Recap] Breaking Through Organizational Inertia and Driving Adoption appeared first on Jama Software.

Jama Connect^® Features in Five: Semiconductor Solution

In this Features in Five session, Steve Rush, Principal Solutions Consultant at Jama Software, introduces our purpose-built semiconductor solution, designed to accelerate implementation and maximize value for your projects.

Key highlights include:

• Ready-to-use project templates tailored for semiconductor workflows, including IP block and core examples.
• A dedicated community space with process documentation, templates, and integration resources.
• Tools for complete traceability, from stakeholder requirements to post-silicon validation.

With these features, Jama Connect streamlines semiconductor development, helping teams manage risks, changes, and traceability with ease.

VIDEO TRANSCRIPT

Introduction to Jama Connect for Semiconductors

Steve Rush: My name is Steve, Principal Solutions Consultant for Semiconductors here at Jama Software. I’m happy to showcase our new Semiconductor Solution for Jama Connect. It gives companies a head start on their Jama Connect implementation, shortening time to value on their investment. Subsegments like integrated device manufacturing, IP, fabless, and design companies can use this solution out-of-the-box from day one. It can also easily be tailored for manufacturing use cases. The solution itself is made of multiple components.

First, there is a new suite of project templates. These illustrate best practices for data model setup and project organization tuned to the semiconductor industry, robust traceability, IP block and IP core examples, and much more.

Our new community space includes process documentation, importable templates and reports, curated marketing assets, and details on common integration use cases for the semiconductor industry.

RELATED: SUSS Chooses Jama Connect to Support a New Standardized Development Process for Semiconductor Equipment and Solutions

Rush: Let’s take a tour of the new projects that come with the semiconductor solution for Jama Connect. You’ll see a few new sets of projects that come with this instance of Jama Connect. First are some automotive examples, one with mock example data, another with microcontroller data showing what an automotive semiconductor project might look like for a particular microcontroller, and then a template that goes along with it for easy copying for a new project.

Our flagship project, which I’ll demo here for you in a second, is the integrated semiconductor system example with GPU data and then the template that goes along with it for easy copying for reuse. And then finally, the semiconductor example data project and template that goes along with it for a hardware-only project.

Let’s take a deeper look at the flagship project, the integrated semiconductor system example with GPU.

This project comes with a new data model honoring the systems engineering bee, illustrating how we decompose the system from a high-level stakeholder Market Requirements Document (MRD) all the way through a a post silicon validation.

High-level stakeholder requirements are derived into system requirements. We call this a Product Requirements Document (PRD) in the semiconductor context. Architectural elements can be linked to the system requirements for allocation. System requirements are distilled into hardware or software domains, respectively.

And then we capture design information as well for those particular domains, separating the requirements from the design, the requirements describing what the system shall do, and the design, how the system will do it. We also have an example project for managing IP blocks or IP cores with a separate hardware block requirement type, design details, and a datasheet item.

RELATED: Transforming Semiconductor Development with Jama Connect’s New Framework

The datasheet item can be used to manage key features of that IP core, which we keep separate and distinct from the requirements item. And then finally, verification and validation for both the stakeholder MRD and PRD levels, as well as pre and post-silicon verification and validation, respectively. You’ll see a project dashboard with some useful widgets, a full requirement breakdown by type, stakeholder requirements MRD rolled up by status, post silicon GPU validation by test case status, and then several examples of filters that are finding gaps in my traceability. This will allow teams to help understand requirements, missing certain coverage, and help them manage risks, changes, and exceptions within the project. The project tree now contains new enriched sample data.

At the stakeholder MRD and PRD levels, you’ll see a folder breakdown helping teams store and manage things such as sustainability, regulatory, and security requirements.

The project structure reflects best practice for organizing your project data, and it includes robust traceability examples that show prospects and customers what complete traceability looks like within Jama Connect.

RELATED: Intelligent Engineering Management with Jama Connect Live Trace Explorer™

Rush: Using Live Trace Explorer™, you can open up sections of the project to see the traceability score, and you’ll see that this one has a one-hundred percent score with complete traceability.

The IP block section provides examples of several IP projects in FP64 computer core and HP M3 memory. These are derived from the system-level requirements, and they come with their own mini model and setup. You will see examples of functional and parametric requirements, detailed design examples, as well as post pre and post-silicon testing and their respective phase gates. We’re also excited to announce a new procedure guide, which you can use with these new templates. These recommend best practices and recommended steps for using Jama Connect for an integrated semiconductor systems project. You’ll see instructions for managing things like the high-level MRD from conception all the way through baseline work product. You’ll also see instructions and examples for reusing those IP blocks in another project or context.

Thank you very much. We’re excited to deliver more examples and content for the semiconductor industry with Jama Connect.

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

The post Jama Connect® Features in Five: Semiconductor Solution appeared first on Jama Software.

This blog is a recap of our recent webinar. To watch the entire presentation, visit “Advancing Requirements Engineering in Semiconductor.”

Evolving Requirements Engineering: A Framework for the Semiconductor Industry

Unlike other industries, the semiconductor sector has no governing standards or regulations for developing and managing requirements and product data— despite being critical components of products across nearly every regulated industry. This absence makes aligning key methods and practices a critical lever for improving quality, reducing rework, and gaining a competitive edge.

In this webinar, Sarah Gregory, Principal Consultant, Systems & Requirements at Crary Labs LLC, and Steve Rush, Principal Solutions Consultant at Jama Software, explore how voluntary alignment on requirements engineering practices can elevate your processes.

What You’ll Learn:

• The current state of requirements engineering in the semiconductor industry
• The value of selective movement to common ground
• “Common enough” methods that deliver measurable improvements
• How to use the Jama Connect^® for Semiconductor Framework and Procedure Guide

Whether you’re defining your next generation of chips or improving process maturity across design teams, this webinar will help you align, simplify, and elevate your requirements engineering practices.

WEBINAR PREVIEW BELOW, CLICK HERE FOR FULL WEBINAR

WEBINAR TRANSCRIPT PREVIEW BELOW

Advancing Requirements Engineering in Semiconductor

Sarah Gregory: Thanks everybody for joining us today for a discussion about requirements engineering in the semiconductor industry. After over 20 years of tackling challenges of requirements within a semiconductor company myself, it’s really great to be collaborating with the folks at Jama Software on the upcoming launch of a Jama Connect solution that’s tailored for what we do. This webinar is an introduction to that solution, kind of a soft launch of a broader set of resources that will be released in just a couple of weeks, significantly expanding Jama Software’s engagement in a sector in so many ways that’s foundational to industries overall. In this webinar, we’re going to give a brief overview of the current state of semiconductor requirements practice. We’ll talk through some challenges that are common to semiconductor, some are drawn from my own industry experience, but also from outside research publications and collaborations. These challenges may sound familiar to you too. And then we’ll also talk about the value of intentional movement towards aligning product development data practices both within your company and or any specific company, but also for semiconductor overall.

And we’re definitely seeing folks start to pick up on that. These aren’t alignments that a third party data model or a standard is mandating for you either, but practices that have a solid return on investment in your context both financially and in terms of quality and efficiency. Better alignment accelerates time to market and helps you respond effectively to change. A phrase that I found useful working in semiconductor about requirements as well as requirements engineering generally is common enough, not identical, not uniform, not standard even, but common enough practices that an organization or team can coalesce around in order to build some efficiencies in their product development practice. There are many ways to move toward alignment on common enough practices, but we’ll share just a few today and Steve will show you what they look like in practice if you were to choose to try them out using Jama Connect. Steve will also introduce the Jama Connect semiconductor framework that will be launching on December 4th the same day as a Jama Software hosted Digital Engineering Summit in San Jose. We’ll tell you a little bit more about that before we end today too.

And of course, we’re going to take some questions. We may not have time to catch them all in our short time together today, but please do put them in the Q&A. What we don’t get to today we’ll try to tackle over the next few weeks and we’ll make available in the semiconductor area of the Jama Software website. Let’s get started. A key first step in any collaborative engineering activity is to make sure that when you’re using a term, you’ve got a shared understanding of what that term means. When each of you signed up to attend today, you brought your own mental model of what we might mean by semiconductor, so let’s take just a minute to orient on that with the model that Jama Software uses describing eight different categories of companies. Now, this isn’t the only way to represent semiconductor and there are certainly different degrees of difference or commonality among these groupings, so don’t get wrapped around the picture here or those categories, it’s just to let you know that yes, semiconductor as comprehended by Jama Software is a very broad and diverse sector with different data management needs.

RELATED: Jama Connect Features in Five: Review Center for Semiconductor Development

Gregory: For example, the requirements for a semiconductor chip, for a chip design, they’re going to different than the requirements for litho and etch equipment to fab that chip. Companies in some of the boxes may also exist in other industry categories and they could be subject to standards in those industries as well, so it’s all a matter of what an individual company does that it informs what information they need to manage and how they need to manage that product data. It’s also possible for two companies or more in the same subsegment to manage their product data in very different ways and then for there to be commonalities in company practices across those lines too. It’s not in the scope of Steve’s and my discussion today to dig into these differences within the segments, much less different data management practices among them. Just know that the work that Jama Software is doing to support requirements engineering and data governance in the semiconductor industry, beginning with this initial release of the new semiconductor solution comprehends the scope.

We have eight categories, a lot of overlap, but just as important so many differences sometimes even within a single company within one of those categories. And it’s those differences, the scope and the breadth of them that is a challenge that in many ways is unique to the semiconductor industry. Several industries, automotive, medical devices, even some areas of oil and gas have prescriptive standards that govern how product data is structured, developed and managed. If you’ve been following Jama Software for a while you’ve possibly noticed a lot of resources that enable companies across those industries to deploy Jama Connect to manage their requirements conforming to those standards. Jama Connect has several predefined traceability information models or data models and specific templates that are purpose-built to accelerate the work of companies that need to meet those standards. In semiconductor, we don’t have such a standard at the point of product definition. You may have your own mental model of the information architecture at your company or at least in the part of the company where you’re working.

And if you happen to work in a standards-adjacent area, for example, your company or the part of the company that you’re in provides devices to automotive, standards that govern the automotive industry may be familiar to you at least for that part of your business. Otherwise, even within the same subsector in semiconductor, you’re going to find a lot of differences, a lot of divergence in how companies may architect their product data. In the absence of prescriptive standards that govern product information architecture a lot of that information architecture has just grown up organically. Now, when you look across semiconductor as a whole you might see some resemblance in some areas, but in others the information to be managed is quite different. No standards, no common regulations, very different products, all leads to a lot of divergence in practice, and that divergence can create drag and inefficiencies. Now, that points to one of the common traits across many companies in the semiconductor industry too.

TO WATCH THE FULL WEBINAR, VISIT:
Advancing Requirements Engineering in Semiconductor

The post [WEBINAR RECAP] Advancing Requirements Engineering in Semiconductor appeared first on Jama Software.

In this blog, we recap our recent webinar, “Managing System-on-Chip (SoC) Complexity: Strategies for Scalable Design”

The semiconductor industry is evolving rapidly, with growing challenges in managing System-on-Chip (SoC) complexity and expanding Intellectual Property (IP) portfolios. How can your team stay ahead while maintaining efficiency and collaboration?

In this webinar, Steve Rush, Principal Solutions Consultant at Jama Software, discussed how Electronic Design Automation (EDA) organizations can adopt a more integrated and controlled approach to IP and SoC management using Jama Connect^®.

This webinar provides key insights and practical guidance, including how to:

• Overcome critical challenges in scaling SoC design and managing growing IP portfolios
• Implement more integrated and efficient workflows using Jama Connect
• Achieve measurable improvements in collaboration, scalability, and development outcomes

Steve Rush: It’s a pleasure to be here today to talk to you about this subject. I’ve worked with many customers and prospects across many different verticals, and semiconductor is certainly a vertical that has its own unique set of challenges. This subject is kind of near and dear to a lot of the conversations that I’ve been having, so I really hope that you find this insightful.

In this webinar, we’ll address some of the challenges that many semiconductor design companies are facing when kicking off SoC projects, leveraging the IP that they’ve already developed. Hopefully the audience out there finds this timely and relevant. We’ll level set a bit on the challenge itself, and then discuss three strategies for scaling SoC projects, along with product administrations to support each strategy, and then we’ll wrap up with some Q&A.

First, let’s start with some definitions: IPs and SoCs, what are they? What do we mean? IP cores, sometimes called IP blocks or foundational elements for systems on chip design. They’re really modular building blocks that are designed and purpose-built, and can be compiled to develop an SoC. An SoC, the system-on-chip, is an integrated circuit that comprises all of the system components onto one piece of silicon, which is made up of different IPs.

Our SoC here contains a processor core, a memory IP network on chip, and then multiple IPs themselves, which in and of themselves might be considered projects. When we zoom in to a particular IP, you can see the multiple components of that IP: the microcontroller that acts as the brain of the IP, designed to perform specific tasks and hold processing instructions. The ROM and SRAM, read-only memory and static access memory, are the internal communication fabric, the on-chip network, controlling multiple components, interrupts, controlling electrical current flow, the IO interface, and the input-output interface, which allows IP to communicate to the outside world.

You might be managing this information in a Jama Connect project for an IP core, multiple projects for multiple IP cores, or even multiple versions of those IP cores, depending on your version management strategy. Now that we’ve level-set a bit, let’s move on to some relatable challenges that you might have found yourself in. As semiconductor companies scale, individual IP projects need to be combined onto a single piece of silicon, these SoCs. As we saw in the last slide, different IPs may need to be combined to compile and build that SoC.

Organizing and tracking which IP, and importantly which versions of those IPs, which might be scattered across multiple repositories following different processes, can be daunting. You can imagine if you’re not using a system like Jama Connect, that might require a lot of manual effort, a lot of copy and paste, a lot of data reentry, and that can feel chaotic. For folks out there that are not using Jama Connect or just don’t have a well-defined process in Jama Connect, you might be relying on a lot of institutional knowledge when the time comes to compile these different IPs to build your SoC.

RELATED: Extending End to End Traceability into the Semiconductor Design Cycle

Rush: Maybe your lead engineer knows which versions of the IPs you need to use, or what third-party software licenses you need to monitor and update, but it’s just not well-documented. You don’t really have a system in place to manage all of this. If someone walks out the door, a lot of that knowledge walks out the door as well. Of course, you do what you can to capture that knowledge, and do a knowledge transfer, but it’s still just a very fragile system that you’re relying on.

Maybe you do have some semblance of a system, but it lacks consistency and unification. The IP core requirements are maintained in different systems, maybe different requirement management repositories. Maybe they’re just documented on Wikis, like Confluence, which comes to mind, but there’s no unifying data model. Without that, this creates traceability risk when you recompile everything to build your SoC project. How can you be sure that you’re completely covered and you have no traceability gaps?

Now, I’m not advocating that everyone has to follow the exact same process down to the T. Some level of autonomy might be necessary for different teams managing different SoC projects, and that is necessary, but there should be some unifying model and some unifying process that teams can follow to address these different gaps and risks. Here’s a slide that might resonate with you all. The current challenges you might be facing, the impact of those challenges, the goals, and business outcomes are all sort of documented here.

This represents a cross-section of a lot of customers and prospects that I’ve been talking to in the semiconductor design industry. The strategies that I’ll discuss and impart today speak to both of those personas: a prospect that’s not using Jama Connect or an existing Jama Connect, that just needs to scale up and optimize their use of Jama. Let’s look and talk about some of these challenges. Customers need to scale SoC management on Jama Connect.

Scale, that can be a vague and overused term, but what I think about when I hear this is that customers are really looking for control, a plan, and a tool with the right functionality to help them manage this complexity. Versions of IPs are scattered across multiple projects or systems. A couple things come into mind right away here: that immediate clarity when it comes to either applying a change, or resolving a defect, or figuring out what third-party software is being used for which project or product, it just is impossible.

RELATED: Compliance Made Easy with Jama Connect® for Automotive and Semiconductor Development

Rush: Future projects are coming down the pike, requiring reusing out-of-context IPs for in-context SoC projects, possibly needing to maintain both the out-of-context IPs and then the new in-context IPs, which make up the SoC. Again, a plan, a process, and a tool are needed to support this. Let’s discuss some of the impacts of these challenges. Disorganization, because you need to manage content across projects or potentially across systems, there can be just a lot of lost time, a lot of lost hours in terms of re-documenting things, and just generally a lot of confusion.

There can be traceability risks, especially if the data that you’re managing does not have a unified data model, or that data is just not integrated across systems. How can you be sure there are no traceability gaps? Future projects just take longer to spin up, because there’s a lot of rework. Yes, you can save that content as and work from there, but syncing those changes across the different copies that you’re making at scale just really isn’t possible without a tool like Jama Connect.

Let’s talk about some of the goals that we hope to achieve by adopting some of the strategies that I’ll outline. We want to scale SoC management, and again, what I think this means is developing a plan, using a tool that can support these use cases, and implementing a controlled yet flexible process. Leveraging libraries and variants to compile your IPs for reuse. This will be one of the strategies that we’ll discuss later on.

Immediate version clarity, both for software licensing and defective change management, and applying those changes across different projects in a scalable way, which leads us to the outcomes. What we hope to achieve by adopting some of these strategies we’ll streamline SoC projects coming down the pike by using and leveraging existing IP in a controlled and organized method. This will give us high-quality source control, using a library approach in Jama Connect, so that defects and changes can be applied to working projects at scale and easily.

Maintaining licensing becomes clearer in this library-managed system, and the path to regulatory compliance can even be eased, as with all the processes we’ve adopted, traceability risks can be mitigated and reduced. A look into live traceability is possible, and we’ll unpack that a little bit later in the webinar today. You can increase time to value, manage change, and increase product confidence with all of these strategies.

WATCH THE ENTIRE WEBINAR HERE:
Managing System-on-Chip (SoC) Complexity: Strategies for Scalable Design

The post [Webinar Recap] Managing System-on-Chip (SoC) Complexity: Strategies for Scalable Design appeared first on Jama Software.

In this blog, we recap our webinar, “Compliance Made Easy with Jama Connect^® for Automotive and Semiconductor Development”. Click HERE to watch the entire webinar.

Evaluate Your Compliance Against ASPICE, ISO 26262, or ISO 21434 with Diagnostic Services Offerings from Jama Software^®

During the webinar, experts Steve Rush, Principal Consultant, and Sampath Yerramalla, Senior Consultant, explored various service offerings within Jama Connect that provide insights into compliance status against these critical automotive standards.

Key takeaways from this webinar:

• Learn about available diagnostic offerings in Jama Connect, such as: ASPICE, ISOS26262, and ISO21434
• Learn about the benefits of diagnostic offerings, how they will expose risks to compliance, and which one is best for your organization
• See firsthand how Jama Connect helps teams reduce unacceptable risks

Discover how Jama Connect can empower Automotive and Semiconductor development teams to evaluate and ensure compliance.

Below is an abbreviated transcript of our webinar.

Compliance Made Easy with Jama Connect for Automotive and Semiconductor Development

Steve Rush: Hi everyone. I’m happy to be here today to take you through the presentation. I wanted to start with a high level agenda and an introduction. We’ll be discussing Automotive compliance in general. To start, we’ll be looking at specific service offerings that you can use to help leverage, to evaluate your compliance against certain Automotive standards.

There are two forces often related that I like to think about when it comes to compliance that really impact the organization as a whole, from engineers to executives and everybody really in between. And those are process and quality. And I like to think about compliance as the intersection of those two often related ideas. Meeting the objectives of these standards may achieve both process and quality, but developing a compliant process and system, this will speed up development by instituting good process and reducing rework. It will help catch and identify defects early in the development process. However, there’s many evolving regulations and standards in this Automotive sector that make the idea of compliance all the more challenging to understand, let alone demonstrate. Perhaps you don’t even know where to start when it comes to achieving compliance in an Automotive system. It might feel like you are building a car while it’s driving.

At the same time tasked with implementing the process and tools to support the process and unsure which should come first. And we want to talk a little bit about this through the lens of compliance and make the case that Jama Connect is a tool well suited to get you up and running quickly, optimized against popular Automotive standards. To assist with this, we’ll discuss the diagnostic that Jama Software offers as a service that’ll help you navigate these important compliance questions. But I fully believe that by meeting the objectives of some of these critical Automotive standards we will discuss today that you’ll balance both process and quality and achieve compliance.

RELATED: Global Industry Leading Automotive Application Developer dSPACE Migrates from Legacy Requirements Management Platform to Jama Connect^®

Sam Yerramalla: Today we are highlighting some offerings that will help guide Automotive customers or prospects like you with your compliance process. We feel these diagnostics can be very helpful whether you are a customer of Jama Software or a prospect. If you’re a Jama Software prospect who’s not yet purchased Jama Connect, these diagnostics makes the case that Jama Connect can help you meet the objectives of the Automotive standards. And namely, there are three standards offerings that we provide. One is the ASPICE Diagnostics, the Automotive Functional Safety Diagnostics, and the Cybersecurity Diagnostics. Now these diagnostics can help you navigate the classic process versus tool conundrum. That is if you’re trying to understand whether you should build the process first or buy the tool first, you’ll first see firsthand how Jama Connect will help shape the process. If you’re a Jama Software customer, you can use these diagnostics as a baseline. Oftentimes, we get busy with our day-to-day work and we may drift away from the larger big picture.

And these diagnostics are meant to guide you to bring light into areas that you need improvement or any optimization of your current Jama Connect process. You can also be paired with a Jama Software consultant or a solutions architect who will take you through the diagnostics start to finish. The time commitment for each of these diagnostics is about two to three hours. We feel that’s reasonable considering the benefits you may get out of this. We focus on the outcomes and the objectives and how this will truly help meet your compliance needs by optimizing your Jama Connect usage. If you’re a customer or getting up and running in Jama Connect, if you’re a prospect who’s looking for purchasing Jama, you can see these diagnostics offerings along with other offerings that we provide on the Jama Software Success Program page at Jamasoftware.com/success. Here you’ll see details on the compliance offerings that we just mentioned and a lot more other offerings including offerings on onboarding Jama Connect, improving your process and requirements, quality, traceability, et cetera.

RELATED: A Wise Investment: Requirements Management and Traceability Solutions During an Economic Downturn

Yerramalla: You can also request an offering if you have a service program with no assigned consultant and our operations team will pair you up with someone. So as far as the Automotive standards and alignments are concerned, the diagnostics offerings that we provide are aligned to the three standards, the Automotive Spice, ISO 26262 and ISO 21434. Only certain areas of those standards are in scope. For example, things like part seven of the ISO 26262 for production and operation and decommissioning are not covered here. But you will see some of these sections here are covered by the diagnostics. So depending on which diagnostics is right for you, the risks that are identified will align to the different areas that you see on the screen. Now, it may be that you want to align to more than one standard. We certainly put you through multiple diagnostics to identify your risks pertaining to each of these standard.

The model which we use is the same, but the recommendation we provide and tailored solution that the diagnostics provides will be custom based on each scenario. And if you don’t know where to get started or you don’t know which of these diagnostics that you need to start first. Some things are obvious, again, that if you’re looking for cybersecurity compliance and that is of the greatest concern for you, then Cybersecurity Diagnostics, the 21434 is right.

And if you’re looking for developing any functional safety products that are used in the Automotive, then the ISO 26262 diagnostics is the correct one to start with. And if you’re looking for any software process improvements or quality management, then ASPICE is the place to start. But sometimes you need both APSICE and functional safety, for example, in which case we suggest the ASPICE Diagnostics first. And the reason is that we rank in the process ASPICE about the functional safety is that if you have a high level of ASPICE maturity or on the other side, if there are several risks that are flagged from the ASPICE Diagnostics, then those will impact your Functional Safety Diagnostics already.

So you would’ve covered those parts of it that as a prerequisite for the functional safety. And then the spirit of ASPICE is really the quality management. And this is important in every engineering organization. So if you’re unsure where to start, then ASPIE Diagnostics is one place. And if you don’t need to prove compliance to the latter, it’s really good because honoring it, the lead benefits in your process.

To watch the entire webinar, visit:
Compliance Made Easy with Jama Connect for Automotive and Semiconductor Development

The post [Webinar Recap] Compliance Made Easy with Jama Connect® for Automotive and Semiconductor Development appeared first on Jama Software.

In this blog, we recap the “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System” webinar.

In this webinar, “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System”, learn about the implementation of the Threat and Risk Analysis (TARA), the centerpiece of the new Automotive Cybersecurity standard ISO 21434.

Many companies currently use spreadsheets to develop TARAs, which can be challenging when managing large sets of requirements across distributed teams and car line variants. In this webinar, we’ll examine why a requirement management system (RMS) is well-suited to manage the TARA work product and can make a significant impact on managing this data across teams, supporting compliance audits, and assessments.

Attendees will gain insights into TARA’s complexities and how the right tooling solution can make a difference in managing this data across teams, supporting compliance audits and assessments.

Key Takeaways:

• The Threat and Risk Analysis or TARA is the centerpiece of the ISO 21434 Automotive Cybersecurity standard
• Overview of TARA
• ISO 21434 compliance requirements when implementing TARAs
• Why an RMS is well-suited to manage TARAs

Below is an abbreviated transcript and a recording of our webinar.

Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System

Kevin Dibble: Thanks, Juliet. Okay. I’m going to just go through the agenda and then get right into 21434. I’ll start with a high-level introduction and then get into the focus of our topic today, which is the threat and risk analysis, which is a centerpiece of 21434, also known as the TARA. And then make an argument for the management of a TARA using an RMS or a requirement management tool. And then Steve will take over and talk about what that would look like in Jama software and summarize with some key points of managing TARAs in Jama versus some traditional methods. And then we’ll have time for some questions.

So with that, again, this is going to be a very high-level overview of 21434. I have a feeling that some of you have worked in cybersecurity for some time, others are just brand new to the term. And so, I want to touch on this as a basis for the rest of the discussion.

And so, first, what is 21434? It is the automotive industry standard for developing cyber secure systems. After several years of review, it was approved in August of 2021 as the method for developing cyber secure systems. In terms of the standard itself, it’s structured and uses a lot of the same terminology as the functional safety standard called ISO 26262. So if you’re familiar with functional safety, then this standard will make a lot of sense the way that it’s organized. Some of the terms such as an item definition, a concept phase, a cybersecurity goal, even TARA parallels functional safety terms like functional safety concept, functional safety goals, or the HARA, Hazard and Risk Analysis. And so, that’s just a reference point as you’re learning about this new standard. Now as far as its scope, it covers or it applies to passenger vehicles and cargo vehicles.

So just a little bit different than ISO 262 there, passengers would include buses, commercial or non-commercial. I think even tripods and some of those other types of motorcycle hybrid type of devices are in or vehicles are in scope as well. It applies to series production and it uses a lifecycle that starts at the request for a quotation for an item. And I’ll define that in a little bit and goes all the way through to the end of cybersecurity support. So like functional safety, we’re not talking about supporting the risks and the hazards associated in this case with threats from attackers leading up to SOP, but it extends far past that. In fact, in 21434, instead of using the term SOP or start of production, which is a critical milestone in any automotive product development program, they call that milestone the release to post-development.

RELATED: Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety

Dibble: And I want to camp on that for just a second because it raises a really important point and it’s very relevant to what we’re going to talk about regarding the TARA. Release to post-development. So the automotive industry is under a lot of change and OEMs want to be or are becoming mobility providers and services will be sold after the car is released. And some of those services weren’t even imagined at the time the car was sold. That’s so different than where the automotive industry was even five years ago. And this standard recognizes that and embraces it along with another important concept, which is that the world of cybersecurity and the landscape for threats and the technologies and the tools that are used to attack vehicles is constantly changing. And so, at the release to production, what is assumed to be protected in terms of say a set of cryptographic keys or a communication bus might be more vulnerable in five years than it was when the car was released because of new techniques, new methods, new tricks, new hacks, and other things that have been discovered.

And so, that’s an important concept because it feeds to our idea that we’re going to get into about the TARA as a living document, as a living asset that begins all the way at the concept phase at the beginning of the high-level architectures of the item or the system in the car. And extends all the way until the end of life for cybersecurity support, which is 10, 15 years down the road. Now, the 21434 has both requirements for developing cyber secure systems, is kind of what I’m showing you on the right, but it also has process requirements. And to that end, there is an audit of the process and an assessment of the results of your project according to 21434. That assessment piece is important for our discussion because when we think about the TARA and the pieces of it or the items of the TARA, then we have to think in terms of what are the evidences we need to leave behind and produce in order to pass an assessment, very important consideration.

RELATED: A Guide to Road Vehicle Cybersecurity and Risk Management: Part 1

Dibble: And so, we have audits for the processes and then assessments for the end result. So that’s very brief overview of 21434. I want to make sure I leave you with the… If you remember anything about 21434 besides the TARA, you’ll hopefully remember this, is to manage unreasonable risk of damage to road users due to a malicious attack to a vehicle or a vehicle data, confidentiality, integrity and availability. Let me unpack that for just a second. Unreasonable risk, this is when you get into a car, when you operate a vehicle, you assume some risk. But that risk doesn’t include driving down the highway at 70 miles an hour, turning right and the car going left or the headlights going off while you’re on the highway at night. It applies to road users. That’s the people that use the road, the driver, the passengers, and the people surrounding it.

All of that is our scope for how we’re going to define threats according to 262 and then mitigate them against malicious attack due to… That’s the cyber aspect of this. And then what’s being attacked and what are we protecting? We’re protecting vehicle systems, functions, data, et cetera. We call them assets according to their properties, confidentiality, integrity and availability. There could be more properties, that’s the CIA that we’re protecting. Why is cyber such a hot topic? Well, I would say there’s several reasons, but here’s two of the big ones. On the left of my slide, the advent of the connected car coupled with the automated driving functions. I’m not going to read through all the stats here, but the connected car is here. It’s 2 billion in terms of the market in 2021 to grow to $5.3 billion in 2026. And the connected car is accessible via the internet, accessible via Bluetooth and other network interfaces, which all result in attack services. It also has a lot more software.

To watch the entire webinar, visit
Why it Makes Sense to Store Cybersecurity Risk Management Items
Inside an Requirements Management System

The post [Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System appeared first on Jama Software.

Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety

Have you heard of FuSA? It stands for Functional Safety, and it is a vital part of any system that requires safety assurance. FuSA was designed to reduce the risk of physical injury or damage due to malfunctioning equipment. This guide will provide an overview of the subject, including the standards, compliance requirements, and the different types of systems where FuSA is used.

What Is Functional Safety?

At its core, Functional Safety (FuSa) is a set of measures taken to ensure that a system meets certain safety requirements. In other words, it’s a way to make sure that any system can operate safely without causing physical injury or damage. This includes both hardware and software components within the system.

RELATED: Managing Functional Safety Development Efforts for Robotics Development

How Does FuSa Work?

The goal behind FuSa is to reduce the risk associated with a product’s failure as much as possible through the use of safety systems that are designed to detect any potential hazards and then take corrective action if necessary. To do this, developers must consider both hardware-based solutions such as monitoring devices or sensors, as well as software-based solutions such as algorithms or machine learning models that can detect potential faults before they occur. Once all potential risks have been identified and addressed, designers must then create a comprehensive test plan to validate all safety system components before the product is released into production.

FuSa Standards and Compliance Requirements

Several international standards have been established to help guide organizations in their implementation of FuSa. These standards include ISO 26262 for the automotive industry and IEC 61508 for industrial manufacturing and consumer electronics sector. Both these standards establish minimum requirements for safety-critical functions within a system. Additionally, each standard specifies certain testing procedures that must be followed in order to demonstrate compliance with the standard.

Typical Applications of FuSa

FuSa is commonly used in aerospace and defense applications as well as road vehicles, industrial machinery, medical devices, consumer products, and more. It can also be applied in critical systems such as those involving control functions or power generation/distribution systems. In all cases, the goal is to reduce the risk of unacceptable physical harm or damage due to malfunctioning systems or components.

When creating a safety system using FuSa principles, engineers typically use several tools such as FMEA (Failure Modes Effects Analysis), FMEDA (Failure Modes Effects & Diagnostic Analysis), FHA (Functional Hazard Analysis) etc., which are all based on the IEC EN 62304 standard for software development processes in medical devices; Road Vehicles Functional Safety Standard (ISO 26262); IEC 61508 for industrial automation; etc., all depending on what type of product/system one has in mind when developing a safety critical E/E/PS (Electronic / Electrical / Power Supply). All these rules vary depending on what type of product is being developed but usually involve assessing potential risks from different scenarios and establishing suitable safeguards against them so that they meet certain Safety Integrity Level requirements laid out by ISO/IEC 61508 standard.

RELATED: 2023 Predictions for Industrial and Consumer Electronics Product Development

Conclusion:

Functional Safety is an important consideration for any organization dealing with safety-critical systems or components involving significant risks from potential malfunctioning equipment or software failure leading to unacceptable physical harm or damage caused by the equipment itself. Engineers must use proper tools like FMEA & FMEDA during development process while ensuring adherence to standards such as ISO 26262 & IEC 61508 while developing their products meeting necessary Safety Integrity Level requirements laid out by these standards. As long as organizations are aware of these requirements and take steps towards implementing them properly into their products & services they should be able to develop reliable & safe products meeting customer expectations!

Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Steve Rush.

The post Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety appeared first on Jama Software.