Tag Archive for: Requirements & Requirements Management Page 13
Tag Archive for: Requirements & Requirements Management
Jama Connect® Features in Five: Jama Connect Interchange™ – ReqIF Import
Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.
In this Features in Five video, Mario Maldari,Director of Solution Architecture at Jama Software, will introduce viewers to the Jama Connect Interchange ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined.
VIDEO TRANSCRIPT
Mario Maldari: Hello. My name is Mario Maldari and I’m the Director of Solution Architecture here at Jama Software. Today, we’ll be discussing the Jama Connect Interchange ReqIF import capabilities. We will review how requirements data from suppliers and stakeholders can easily be imported into Jama Connect, where they can be further elaborated and defined. With Jama Connect Interchange’s ReqIF file-based exchanges are simple and streamlined regardless of what requirements management tool is used by the supplier. The tool’s automatic and intelligent field mapping helps to facilitate a smooth import process ensuring all data comes into Jama Connect as expected. This includes field and data mapping as well as maintaining upstream and downstream traceability between various requirements. Let’s explore how this works with Jama Connect Interchange.
We have received a ReqIF export from one of our many suppliers. This particular file contains a mixture of system requirements and subsystem requirements. We have worked with our supplier to define fields and values for the requirements. The system requirements contain tolerance values and due dates that were set in the originating tool. It also has subsystem requirements that contain a Boolean value named Compliance, which is set to true or false. We’ll be using Jama Connect Interchange to create a conversation, map our attribute fields, and import into Jama Connect.
Maldari: The first thing we will do is to create a conversation that will define the context of the import. We will choose a Jama Connect project that we would like to import the ReqIF file into and provide a name for the conversation so that we can refer back to it at any time to perform additional imports or exports. Once completed and saved, we can select on the Import tab. This is where we will upload our ReqIF file and prepare for the import. We can select a location in the Jama Connect project for where we want the requirements data to be imported into. We will create a simple mapping of the requirement types found in the ReqIF file to the desired and corresponding requirement types in the Jama Connect project.
Once this is achieved, we can point and click to map our labels and attributes. First, we’ll map the labels for our system requirements. One of the great things about Jama Connect Interchange is that it automatically detects the type for you during the upload process, so that you can easily perform a corresponding mapping into Jama Connect. This helps save time during your imports. It also takes the guesswork out of manual mapping. In this case, we’ll map four values, name, description, tolerance, and due date. The field mapping can easily be toggled on or off, depending on the data you want to map and import. Next, we will map the labels for our subsystem requirements. In this case, we’ll also map three values, name, description, and compliance.
Finally, we want to ensure that whatever relationships and traceability that existed in the source system are mapped over when imported into Jama Connect. Let’s go ahead and include the relationships, and we can even select the relationship type that we would like the requirements to have when imported. Once our desired mapping is complete, we can click the Initiate Import button to begin the import process. In this case, we’ll create new items. However, if we’re performing a round-trip exchange and we had already imported, we can easily update the items with changes made by our supplier during the import process. All events are logged in Jama Connect Interchange so that it’s easy to check on status and progress. Let’s navigate over to our Jama Connect project to see the imported requirements.
Maldari: As expected, we see both system requirements and subsystem requirements. We can take a look at each and verify that the name, description, and other fields such as tolerance and compliance have also come in populated with data. We can view the relationships in traceability using our trace view to ensure that the traceability from the source system has been maintained. We can easily modify any of the values in these fields and change them according to our working process in normal requirements management activities. We can continue elaborating these requirements in Jama Connect or export them using Jama Connect Interchange to share back with our supplier at any time. Many requirements’ management tools have implemented their own version of ReqIF making interoperability a challenge. Only Jama Connect provides interoperability with ReqIF, making imports and exports easy regardless of their originating source.
Thank you for watching this Features In Five session on the Jama Connect Interchange for ReqIF import. If you’re an existing customer and want to learn more, please reach out to your customer success manager or consultant. If you’re not yet a client, please visit our website at Jamasoftware.com to learn more about the platform and how we can help optimize your development process. Thank you.
In this blog, we’ll recap a section of our eBook, “Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects” – Click HERE to read the entire thing.
Fueling Progress: Solutions to the Biggest Challenges Slowing Oil & Gas Projects
The oil and gas industry is a cornerstone of the global economy, but it faces a growing set of challenges in an increasingly complex and competitive landscape. From fluctuating market dynamics and stringent
environmental regulations to technological advancements and the demand for operational efficiency, companies in this sector must navigate a series of critical obstacles to remain resilient and sustainable.
In this eBook, we explore the top challenges shaping the future of the oil and gas industry, providing insights into how businesses can adapt and thrive amid these shifting pressures.
Energy Transition and Decarbonization
The global shift toward clean energy and reducing carbon emissions poses a significant challenge for oil and gas companies. The pressure to decarbonize operations, meet regulatory standards, and invest in renewable energy sources is growing. Balancing the need to reduce greenhouse gas emissions while maintaining energy supply and profitability remains a key issue.
Investment in carbon capture, utilization, and storage (CCUS) technologies is becoming crucial for oil and gas companies as they seek to reduce their carbon footprints while continuing operations. CCUS can help mitigate the environmental impact of fossil fuel production by capturing CO2 emissions before they are released into the atmosphere. Additionally, oil and gas companies are increasingly expanding into renewable energy sectors like solar, wind, and hydrogen to diversify their portfolios and align with global efforts to decarbonize energy. Navigating complex carbon regulations, such as emissions trading systems and carbon pricing, also requires strategic planning to minimize costs while meeting government and international compliance targets.
KEY CONSIDERATIONS
Investment in carbon capture, utilization, and storage (CCUS) technologies.
Expanding into renewable energy sectors like solar, wind, and hydrogen.
Navigating complex carbon regulations and pricing mechanisms.
Volatile Market Conditions
The oil and gas market is highly sensitive to global political, economic, and environmental factors. Fluctuations in oil prices due to geopolitical tensions, supply chain disruptions, or demand fluctuations (such as those caused by pandemics or global economic shifts) can severely impact profitability and investment planning.
Geopolitical risks, such as conflicts in oil-producing regions or shifts in international relations, can lead to sudden and significant fluctuations in oil prices. This volatility is further exacerbated by disruptions to global supply chains, economic recessions, and unpredictable demand patterns due to factors like pandemics or rapid changes in energy consumption behavior. Oil and gas companies must remain agile, continuously assessing market conditions and adjusting their production strategies accordingly. Managing these fluctuations requires strong financial risk management, flexible supply chains, and forward-thinking strategies to hedge against market downturns.
KEY CONSIDERATIONS
Geopolitical risks, such as conflicts in oil-rich regions.
Supply and demand imbalances.
Economic slowdowns affecting global oil consumption.
Technological Innovation and Digital Transformation
As the industry evolves, there is increasing pressure to adopt new technologies that will improve operational efficiency, safety, and sustainability. The integration of digital tools like artificial intelligence (AI), automation, and the Internet of Things (IoT) can help reduce costs and improve performance, but the high cost of implementation and cybersecurity risks are barriers.
Digital transformation in the oil and gas industry presents an opportunity to enhance operational efficiency, but implementing these technologies comes with challenges. Predictive analytics, driven by artificial intelligence and machine learning, can optimize production processes and enable predictive maintenance, which reduces downtime and improves asset longevity. However, with the increasing reliance on digital systems, cybersecurity risks also rise, making data protection a critical concern. Additionally, digital transformation requires a workforce with new skills, and companies must address these gaps through retraining and attracting tech-savvy talent to ensure successful implementation of these innovations.
KEY CONSIDERATIONS
Leveraging data analytics for predictive maintenance and production optimization.
Enhancing cybersecurity in increasingly digitized operations.
Addressing workforce skill gaps to support digital transformation.
Oil & gas companies that develop products such as undersea robots that support exploration and delivery face their own set of challenges. First, the use of document-based technology or siloed point software solutions fails to keep up with the increasingly complex hardware and software systems and subsystems that must perform flawlessly together. Second, reliance on manual tools that are not optimized for managing a complex development process often results in inefficient teamwork and late detection of defects.
As a result, companies find themselves:
Relying on inefficient meetings or email communications involving internal, partner and supplier teams to discuss, review and approve product requirements and tests
Missing opportunities to detect defects and other issues early in the development process when it is typically easier and less costly to ensure product quality and performance
Incurring contractual penalties or losing revenue due to delayed availability or delivery of products
In this blog, we recap a section of our Datasheet, “Jama Connect for Defense Systems: Integrate DoD MIL-STE-882E Risk Management with Systems Engineering” – Click HERE to read it in its entirety.
Integrate DoD MIL-STD-882E Risk Management with Systems Engineering Using Jama Connect® for Defense Systems
Align hardware and software systems safety using Jama Connect as your single, secure platform for requirements engineering, risk analysis, and test management.
Military departments and defense agencies must follow the MIL-STD-882E Standard Practice for System Safety to ensure safety throughout the entire lifecycle of military systems, including development, testing, production, use, and disposal.
A key challenge to compliance is the need to integrate risk management and collaboration into the systems engineering process systematically across system and fire protection safety and occupational and environmental health disciplines.
Relying on a manual, document-approach using Word and Excel to manage the MIL-STD-882E risk register is inefficient and error-prone. A more reliable and intelligent solution is Jama Connect for Defense Systems which provides a single, secure platform for requirements, risk, and test management throughout the development lifecycle. It enables alignment of software and hardware development teams to achieve speed and quality, auto-detection of safety and environmental hazards and risks for early identification and mitigation, and robust collaboration and reviews involving internal teams, supply chain partners and government agencies.
Align the hardware and software systems’ team safety activities. Manage risk management for hardware and software system safety in Jama Connect which provides a single source of truth that integrates with best-of-breed software tools chosen by various teams.
Identify hazards and risks for early mitigation. Teams benefit from a single system and integrated data model for architecture, hazard assessment, analysis, safety requirements, and tests.
Accelerate development by streamlining collaboration and reviews. Avoid development delays by making it easy for internal and external teams to participate in MIL-STD-882E activities with Jama Connect’s Review Center and collaboration intuitive capabilities.
Get the most out of your requirements management and traceability solution. Use the same Jama Connect solution for managing and documenting your product requirements AND your MIL-STD-882E activities to maximize your return on investment from Jama Connect.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.
In this blog, we recap our webinar, “Key Systems Engineering Skills: Critical Thinking and Problem Framing” – Click HERE to watch it in its entirety.
Key Systems Engineering Skills: Critical Thinking and Problem Framing
Elevate your team’s success by exploring the role of critical thinking in a system engineering competency model.
In this insightful session, Chris Unger, Retired GE Healthcare Chief Systems Engineering Officer and Principal at PracticalSE LLC, and Vincent Balgos, Director of Medical Device Solutions at Jama Software®, discuss how critical thinking and decision-making skills are integral to systems engineering.
In this insightful session, you will learn:
Explore the vital role of critical thinking and decision-making in systems engineering.
Learn practical techniques for decision framing and closure.
Gain insight on how systems engineers should manage design decisions on a project.
See a simple model of how and when to engage with stakeholders in design decisions.
Below is an abbreviated transcript of our webinar.
Chris Unger: We’re going to talk today about a follow-up to the last webinar, where I’m going to talk about some of the most important systems engineering skills, critical thinking, and problem framing. So, how do skills in general, and soft skills, fit into improving systems engineering? So, in prior talks, I’ve suggested you keep your processes very simple but make them effective, and that’s easy to say but hard to do. That means you have to understand the system of the SE processes, how they connect, and where the diminishing value of the processes, the source process heading off, happens. As an example, a topic could be a technical risk, or it could be a trade-off between different possible solutions. So, we want to understand how those to the risk management and the decision process interact.
In order to do that, the best systems engineers have to have really good judgment. In addition, we have to influence people. Being simplistic, hardware and software engineers design things, things do what they’re told. I know it’s oversimplified, but our deliverables are instructions on how the software and hardware engineers do things. So, the best systems engineers here have an area of depth that they’re experts in, so they bring some technical credibility. They have systems of breadth, they understand all the systems processes and how they interact, and they have great interpersonal skills. Today I’m going to focus on how you achieve a balanced and optimized design, how you focus on your cost versus risk, and doing that through basically decision making.
So, first I want to talk about the Helix Model. So, the Helix Project was a project funded by the government and, the US government, and their concern was for big aerospace and NASA projects you tend to produce a major, billion-dollar development every 10 years, and then you do 10 years of support. So, people often move on. They were worried about how you create the truly brilliant leader systems engineers from a team that may be a little bit sparse. They developed this model up here in the front and simplistically, you start with things you learn in school, how to do good mechanical engineering, electrical engineering, and software engineering techniques. You then go into an organization, and so you spend the first five years learning about your company. Things like, well, if you’re going to be doing a say glucose monitor, what does blood chemistry look like? What does a sensor look like? What’s a workflow? So, you become a good organization-specific mechanical engineer.
Then you learn about lifecycle. How do you go from womb to tomb, from customer needs to disposal and disposition with all the regulations across the world in terms of chemical safety? So, after five, maybe 10 years, you understand your domain, you understand the lifecycle and you understand your technology. What differentiates after that? What they found was the skills on the bottom half of this page, the Systems Mindset, so big picture thinking, and paradoxical mindset. You’ve all heard that joke about fast, good and cheap, pick two of the three. Well, that’s the world in which systems engineers live. We make trade-offs between things that are inherently conflicting. The other thing is, we’ve got to make decisions quickly, so you’ve got to have a flexible comfort zone. You’ve got to be willing to wait till you have the critical information but make a decision without all the information you want.
Unger: In terms of the middle column, Interpersonal Skills, just the obvious stuff as I mentioned. You’ve got to influence the other engineers to make a good decision. Then finally here in Technical Leadership, balanced decision-making, and risk-taking. So, I had a general manager one time say, “We’re in the business of managing risks, not avoiding risks.” The least-risk program is also a boring one, but you also don’t want to take moonshots and everything. So, you really want to balance. It’s another case of a paradoxical mindset. Balance risk-taking with hitting a schedule predictably. So, these are the kinds of skills that really differentiate as systems engineering leaders, 10 to 15 years into your career. I’m going to talk more about these, decision-making, stakeholder management, and barrier-breaking.
So, I put together a very simple Systems Engineering Competency Model. I started with the NASA handbook and the NASA lifecycle. I simplified it, into that they had scope and requirements management separated, and I actually agree with those being different. But in reality, on the size of programs that we typically implemented, the people who did one typically did the other. Same thing, the architecture and the design, those were typically the same people. So, you have the upfront design, you have implementation. So, managing the subsystems actually do the implementation of what the design asks them to do, and you integrate it, such that you find your defects early. Then you manage all the lifecycle, the serviceability, manufacturability, disposability, and all the “ilities.”
Then leadership, obviously, there the interpersonal skills. This was developed for GE Healthcare, so I just picked it from our existing leadership skillset and I simplified it. What you’ll notice here is I put down at the bottom, critical thinking, as a technical skill. For many executives, and for other functional engineers, critical thinking is important, but as I mentioned, since we deliver instructions and designs to other engineers, framing decisions, taking vague things from product management and marketing, and turning them into clearer problems or functions to solve, I consider that a core technical excellence of systems engineering. But that’s vague. How do I actually measure that? So, I came up with this fairly simple set of observable behaviors. So, first of all, framing problems takes an ambiguous problem identifies the critical stakeholders, and turns them into a clear problem a more junior engineer can solve.
So, first, let’s talk about framing the problem. Even an entry-level person has to be able to understand a problem that’s been framed for them. But as you get to more senior people, the 10 to 15-year level, you have to be able to frame a complex problem, see around corners, use foresight to sort out essentials from the detail, and identify risks and emergent behavior that need to be incorporated in the decision, that other engineers might not see. Even at the strategist level, you can take a complex and ambiguous problem clarify the ambiguity, and turn it into simply just a complex and interconnected problem.
So, if we’re talking about maybe the 10 to 15-year-old person, not the most senior executives, you’ll be able to take a complex problem, identify ahead of time problems other people don’t see, and capture that. Balance cost, schedule, technical risk, and team capabilities, and make a trade-off based on sound evidence and data. Balance your intuition, when you don’t have all the data with waiting and gathering data where you need it. Then finally, making the decision is maybe the easy part. You have to make sure the team follows your leadership. Take accountability for making the right decisions, delegate where you can, and then ensure that the entire team buys into the decisions that the team or you have made. So, that’s the theory.
Unger: Let’s talk about how we manage design decisions. First of all, why? Why is this a critical skill? By identifying the critical design decisions, it allows the team to focus on the most important thing, and separate out the core from the distractions. It helps teams identify work items. So, for example, one time when I was working with the ultrasound team in Japan, we had a bunch of really experienced engineers and they were working on a new ultrasound probe. It had moved an active component into the probe and there was a thermal issue. They were talking in Japanese for about five, 10 minutes when I was asked to frame the problem and I said, “Yeah, you’re talking too fast and too much. This is not that easy. Come back to me and tell me what you’re actually doing.”
They were figuring out how to measure the thermal properties in the lab. I said, “Well, imagine you had a probe that was safe, with maybe 39°C, but that was uncomfortable to handle. Have you worked with the application people on how much value? If you spent $50 more and took the temperature down by 1°C, would that be worth a trade-off? The team, “Oh, that’s interesting.” They were actually focused on the technical feasibility, not the real market and customer acceptance problem. So, by doing this upfront, you can make sure that you have a complete work process for the team. Then once you’ve made the decision, it minimizes rework by making sure the decisions stay closed.
Now, this decision list and prioritization should start early. It would be comfortable to wait until you know everything, but that’s too late. So, it’s a living document. Don’t wait to get started until you have enough information to make a good plan. Start with what you know, and then build out as you continue. So, one of the first things I talk about is, what is a decision? As an example, I’ve had teams come to me saying, “The operating system selection is a decision.” It’s like, “No. It’s actually not typical. It’s typically a collection of decisions.” So, I draw this little arrow here. It’s basically a decision is a point in which you select between different paths going forward and you pick one way versus another. So, deciding whether to include a stretch item in scope or not is a decision. Deciding between very specific designs and implementing a feature is a decision. Setting a critical to-quality parameter or balancing between different parameters, so cost versus reliability or cost versus performance, is a decision.
In this blog, we recap a section of our whitepaper, “Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls” – Click HERE to read it in its entirety.
Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls
Reduce the risks of product rework and recalls by using tools that enhance the efficiency and accuracy of requirements management and aid in compliance with UL 4600, the Standard for Safety for the Evaluation of Autonomous Products.
The shift to software defined vehicles (SDVs) marks a pivotal change in the automotive industry’s journey toward full autonomy. Initially, there was a rush toward developing fully autonomous vehicles, but the complexity of this task led the industry to adopt a more gradual, phased approach. This market transition has given rise to SDVs, but unlike traditional vehicles, which remained largely unchanged after purchase and are based on dated architecture topologies, vehicle OEM’s can now scale their software investments and simplify and optimize the vehicle architecture. This has benefits not only for the developer — resulting in a reduced total cost of ownership, potential acceleration of development, and improved safety and security — but also for the consumer in the form of increased choice, new business models, and post-sales updates and fixes.
Improving product and software development processes and the tools that support them can more effectively enhance safety and security standards while mitigating the risk of costly midcycle rework and after-sales recalls.
In 2023, there were over 300 recalls affecting more than 25 million vehicles, with costs potentially reaching millions of dollars per recall.
The automotive industry has advanced significantly from even a decade ago. Once-basic features, like touchscreen navigation, have evolved into sophisticated connectivity options, voice assistance, app ecosystems, and more. These changes bring several development challenges, including:
Managing increased software complexity
As vehicles become more software defined, managing multiple software components provided by many different vendors that perform entirely different functions increases complexity. For instance, an electronic control unit might operate the antilock braking system, while a cockpit domain controller is responsible for a very different task. In a software defined vehicle these distinct software systems must work seamlessly across the vehicle without issues, adding further complexity to an already challenging development cycle.
Ensuring functional safety and security compliance
With increased complexity, automotive companies face additional challenges in keeping up with safety and security standards and the associated regulatory compliance. The development community has relied on ISO 26262 for many years as the required functional safety standard. But, while it has historically served as an excellent baseline, the standard did not account for software defined vehicles, autonomous vehicles, or many of the new use cases.
Standards are evolving to keep up, and new ones, such as UL 4600, have been created that directly tie to autonomous vehicles. However, these standards continue to require companies to build requirements, test those requirements, and demonstrate that they have done everything possible to build a safe and secure product.
The process is complex with SDVs, especially when considering the hundreds of millions of lines of code involved. Companies must show that no faulty code exists and that they have not inadvertently introduced back doors that could create security issues or conditions that could violate a safety goal. As a result, there is a need to reconsider old processes and tools for requirements management to meet the current development environment and support mitigating potential risks.
Difficulty in meeting accelerated timelines
The pressure to deliver products and software faster is a significant challenge. Technology evolves rapidly, and no sooner have you developed a vehicle than consumer needs and opportunities emerge, leaving you to redesign to keep up with the market, differentiate, and stand out.
However, meeting accelerated timelines can conflict with maintaining quality and compliance, making it critical to strike the right balance. Adopting tools that allow for automation and faster processes can help keep up with these demands while aligning with safety requirements and standards. As more and more companies adopt an Agile development methodology, it’s increasingly important that the associated development tools do not stifle the benefits that Agile can offer. One great example is the concept of Traceable Agile™ that facilitates instantaneous, in-cycle insight into coverage for Agile development teams.
Managing the dramatic increase of third-party software
Advancements in automotive development have led original equipment manufacturers (OEMs) to source software from multiple vendors. Integrating this level of diverse software while avoiding safety and security issues can be challenging. Now, you not only have to integrate hardware from various suppliers but also manage a massive software bill of materials (BOM) from different vendors, ensuring that everything works seamlessly together.
You also need to ensure that you’re not introducing bugs due to incompatibilities between systems, which can cause unexpected glitches, security vulnerabilities and safety issues. These are very expensive, can potentially delay product launches, and create negative brand impact.
Often, hundreds or even thousands of software elements come together, with tens of millions of lines of code. Ensuring that all these elements work together while remaining safe and secure, and meeting consumer expectations for a modern vehicle, is critical.
Four Major Challenges with Software Defined Vehicles
1. Managing increased software complexity. The industry is shifting quickly due to the integration of software in vehicles, which presents challenges in effectively and efficiently developing and deploying SDV’s.
2. Ensuring functional safety and security compliance. Automotive companies face challenges meeting safety and security standards and regulatory compliance, particularly with complex software systems.
3. Difficulty meeting accelerated timelines. The pressure to deliver products faster in the SDV space is a key challenge.
4. Managing the dramatic increase of third-party software. OEMs are sourcing software from multiple vendors and integrating this level of diversity while avoiding safety and security issues is difficult.
Solid engineering practices involve deciding what to build, defining a set of requirements, building it, and then testing it. This development lifecycle process ensures that you’re solving for the correct problem and is centered around requirements management.
However, many organizations use Excel sheets or Word documents to house requirements. Initially, this approach might not seem problematic, but as products become more complex and requirements grow, the spreadsheet approach becomes unmanageable. Copying and pasting requirements across documents creates opportunities for errors, a lack of a single-source-of-truth and a lack of traceability introducing the risk of expensive product or software issues.
You can address this challenge by replacing legacy processes involving spreadsheets and other solutions with a more robust, automated tool specifically designed for requirements management. This change eliminates manual processes that open the door to errors, improves efficiency, and reduces the risk of missed requirements — resulting in potentially millions of dollars of savings.
How Ford Selected a Single Requirements Tool for SDV Architecture
In 2022, Ford selected Jama Connect as a single requirements tool. The company started to deploy the tool focused on the development of a future software defined vehicle architecture.
Before Adopting Jama Connect
Engineers often lacked formal training in writing requirements.
Unconstrained natural language often contained large specifications (non-atomic).
Poor requirements were the standard, and engineers had no automatic ways to receive feedback.
Suppliers received thousands of requirement specifications in PDF, but some didn’t apply.
Signing-off on products was a manual process, with engineers often having to chase down test results.
After Adopting Jama Connect
Requirements engineering is a discipline with training easily available and just-in-time.
Engineers receive immediate and automatic feedback on requirements quality.
Product-line engineering automatically defines what is applicable to a variant of a product.
Dashboards show real-time and transparent progression of product sign-off.
In this blog, we recap our recent webinar, “Achieving ASPICE 4.0: Overcoming Key Challenges” – Click HERE to watch the entire thing.
Achieving ASPICE 4.0: Overcoming Key Challenges
The path to ASPICE 4.0 compliance can be complex. Gaining a deeper understanding of traceability requirements, process consistency, verification criteria, and special characteristics is essential to improving your development processes and achieving compliance.
How to implement robust traceability methods for ASPICE 4.0
Techniques to maintain consistency across processes
How to define and implement effective verification criteria
The significance of special characteristics in automotive software development
BELOW IS AN ABBREVIATED SECTION OF THIS TRANSCRIPT
Ronald Melster: Thank you for the warm introduction and thank you very much for inviting me to today’s webinar. I’m excited to be here with all of you to discuss the challenges and updates that we encounter in the latest version of the ASPICE standard. So let’s get started and explore what these changes mean to our industry and how we can best adapt to them. Why are we doing this webinar? The release of ASPICE 4.0 has brought new requirements and expectations and created some confusion.
In this session, we will discuss four key areas of change that are especially challenging and potentially misleading. This webinar is designed to clarify these updates and help you understand the implications. Here are the four changes I will talk about. First, we will look at the changes on how to connect elements across the V-model. Then we move on to consistency, as there is an increased emphasis on maintaining consistency across work products. I would share how this topic impacts your daily work. Then we discuss our favorite topic, the verification criteria. The base practice and the work product for the verification criteria have been removed from the standard. The question is if the need for a verification criteria is gone as well. And the last change I will talk about today are the special characteristics. This new concept was introduced with PAM for 0.0. I will explain why this is necessary and how it can be implemented.
Some of you may know me already, but for those of you who don’t yet, let me introduce myself briefly. I’m Ronald Melster or simply Ron in the automotive world. As one of Europe’s longest-serving ASPICE assessors, competent since 2005 and now principle, I’ve dedicated my career to guiding organizations through process improvements, always striving to balance structure with pragmatism. After my early work in software engineering and quality assurance at Fraunhofer, where I researched on knowledge management and 3D visualizations, I entered the automotive industry in the year 2000. Over the years, I found that meaningful assessments involve much more than simply rating. It’s about helping people to understand the why behind each process. Today, I coach companies and teams through their ASPICE improvement projects, working with companies like Bosch, Audi, and Porsche to help them reach the capability levels one, two, and even three. Together we are shaping more effective motivated teams that understand not just the how, but the purpose behind the ASPICE standard.
Melster: The first topic I will talk about is traceability. A very common misunderstanding is that a trace must be a direct link to click on, and then I end up at the target element. This was never the expectation and has been clarified with PAM 4.0 in the respective VDA guidelines. Before I run you through the possible traceability techniques, let’s discuss why traceability is essential for successful project management and product development, starting with the impact analysis of change requests. Traceability allows us to clearly track the origin and implications of each change request. By establishing traces, we can see where a change affects other components, documents, or requirements. This is particularly crucial for ensuring that safety and security requirements are met consistently. Next, we have root cause analysis of problems. With traceability, we can identify not only the immediate issue, but also trace it back to the process step where it was introduced.
This can help to prevent similar issues in future cycles by allowing us to adjust processes or documentation at the root cause level, instead of merely fixing surface-level symptoms. And traceability can help to show the completeness of work products. Traceability helps us to verify that all necessary parts of the system are complete and that each requirement has been successfully implemented. This is especially critical in safety and security cases, where missing traces could mean non-compliance or safety issues, or vulnerabilities.
Finally, traceability enables progress tracking. By using trace links, we have a clear and consistent overview of how far along each requirement is in the process. This enables project managers to track progress more accurately. In essence, traceability ties every piece of the project together, ensuring that we understand the why and how behind each element, and helping us maintain quality, safety, and security. Let’s have a look at the first traceability technique, which are naming conventions. The idea is to use the name of one artifact to identify another artifact. For example, the name of the unit, which is defined as part of the detail design, is used to identify the source code file or the function in the source code. Of course, the naming convention has to be described in a central document to make it available to everyone in the project.
Our next traceability technique are editorial references. This method uses the same ID as a text reference across documents that need to be connected. It’s a straightforward approach, often called traceability light, because it doesn’t require complex tools at the start, just the ability to update text in both documents. The question remains how to trace back. There are a few approaches that we can take. The first one is contextual searching. In the traceability strategy, we can specify how to search within the databases or text documents for these IDs, allowing to navigate across documents. Another method is to create a mapping table serving as a lookup tool that aligns IDs from one document to another. Finally, we can use tools like Rectify, that scan the text documents and provide statistics about the coverage of the traces.
Melster: Our third traceability technique is hyperlinking. This approach creates direct connections between tools, making it easier to trace items across different systems. With hyperlinking, each item has a direct link embedded in the document or tool, so rather than manually searching for information, you simply click the hyperlink and it brings you straight to the related item in another tool or document. Our fourth and last technique for establishing traceability are tool links. Many modern tools can create direct links or traces between different elements or requirements, streamlining the process of tracking dependencies and relationships across the project. Tool links often add semantic context to each trace, such as implements or is implemented by. This provides clarity on how the elements are related, making it easier to understand the purpose behind each link. One powerful feature these tools provide are suspect links. These are automated flags that notify us when a linked requirement or element is modified. This way we can quickly perform impact analysis and assess whether changes in one area affect other linked elements, helping us manage risks and ensure consistency across the project.
Another change that comes with PAM 4.0 are clusters of elements. This means that instead of establishing links from one single element to another single element, we can now create traceability links at a higher level. For example, we can trace groups of requirements that share common goals, we can trace two architectural elements within a particular subsystem, or we can trace software units associated with a specific functionality. This flexibility allows us to handle complex systems more efficiently, as we are not restricted to tracing every single element individually. However, this comes with more responsibility, as it is more important to remember that the level of traceability must still be appropriate for the product, and it is more complicated to provide the statistics for coverage, because we cannot just simply count items which are connected. And finally, the justification for consistency becomes much more important. For example, do the test cases which are linked to a cluster of requirements completely cover this cluster, or is there something missing?
Another important change I would like to highlight is that it’s now possible to trace from stakeholder requirements on SYS.1 directly to software requirements SW.1. There is no need to link via the system requirements to the system architecture to the software requirements anymore, if the stakeholder requirements are specific enough and have no impact on any other part of the system other than the software. This approach is often used in software-only projects, where the stakeholder requirements are already very specific. However, in system projects, the impact on the system must be considered in a comprehensive way. The same approach can be used for hardware requirements and mechanical requirements as well.
Another big change from PAM 3.1 to 4.0 is that there’s now a combined base practice for traceability and consistency. In ASPICE PAM versions 2.5 and earlier, we used to assess consistency and traceability together in one based practice. In PAM 3.1, they were split into two based practices for traceability and consistency, and VDA guidelines define the strong relationship between these two base practices, because these two concepts are inherently connected. To explain why, let’s consider this. Consistency depends on having effective traceability. Without solid traceability between work products, we are not able to guarantee that the elements align correctly throughout the development process. For example, if requirements are not traced to elements of the architecture or test cases, showing the evidence for consistency between these artifacts becomes nearly impossible. Therefore, checking for both consistency and traceability as a unified practice makes sense, as it ensures that all pieces are in sync and meet the intended quality standards.
Melster: Let’s have a closer look at an example for consistency, which base practice or base practices in SW.1. Software requirements analysis deal with consistency. Obviously, base practice five directly addresses consistency by requiring us to establish bi-directional traceability between software requirements and the system architecture, and software requirements and system requirements. This base practice ensures that each software requirement is directly aligned with the system architecture and linked back to the respective system requirements. The idea here is to maintain clear connections, ensuring that the requirements are accurately reflected across all levels of design. The second base practice, which deals with consistency is base practice number one, it’s a little bit hidden in node two. This node defines characteristics for requirements like verifiability, comprehensibility, freedom form implementation and surprise surprise, not contradicting other requirements, which is the synonym for consistency.
So we have two types of consistency in software requirements, external and internal. External consistency ensures alignment between software requirements, system requirements, and the elements of the system architecture. Each of these checks involves typically two different documents and it compares different artifacts, software requirements with system requirements, and software requirements with the elements of the system architecture. This is why I call this consistency, external consistency. And we have to fulfill BP-1, which can be done checking for internal consistency. For SW.1, that means software requirements are checked against other software requirements. This activity is essential for ensuring the integrity of our requirements. The primary goal of this verification is to ensure that the requirements do not contradict each other. There are many references and standards such as ISO IEEE 29148, ISO 26262-8, and the INCOSE Guide for Writing Requirements. They have one characteristic in common, that requirements shall not contradict each other.
This is one of my favorite topics. I have had discussions about this for years. Do we need an explicit verification criteria, yes or no? Now the base practice and the work product have been removed. What does this mean? This removal of the explicit verification criteria requirement in ASPICE PAM 4.0 marks a significant change, streamlining the base practices for evidence of verifiability. While previous versions of ASPICE emphasized having a separate verification criteria as a formal step, this requirement has been softened in PAM 4.0. However, demonstrating variability remains a crucial practice as we have seen. Projects must still make sure that there’s an evidence that each requirement is verifiable, though it’s no longer mandatory to document a distinct verification criteria for each requirement. This adjustment suggests that verification is evolving in focus. Instead of a string and isolated criteria, there are other ways to ensure the verifiability, performing review by the test team for example.
Melster: This ensures that requirements can be tested or writing simpler requirements if this is possible, of course, but for straightforward requirements, there’s no need to have an explicit verification criteria. However, for more complex system requirements, writing a verification criteria might still be recommended, so writing a verification criteria has become a best practice instead of a base practice. The decision and the responsibility for justifying this decision lies with the development projects now. And the last topic I would like to talk about are special characteristics. What are they and where do they come from? These special characteristics are often identified through structured risk assessments, such as FMEA, failure mode and effects analysis, which is commonly used to prioritize potential failure risks. Or HARA, hazard analysis and risk assessment, which helps identify safety critical elements. And of course TARA, threat analysis and risk assessment, which focuses on cyber security and vulnerabilities.
In terms of application standards, like IATF 16949, specify that these special characteristics should be integrated into the system architecture, as well into the hardware design. This ensures that all key attributes affecting system safety and compliance are identified from the start. An essential part of managing special characteristics is ensuring that they are verifiable. According to VDA volume one, special characteristics must be documented in a way, so that they can be reviewed and validated. This verifiability ensures that all compliance and safety requirements are traceable and systematically implemented. This concludes our little journey into the changes and challenges with PAM 4.0. If you want to learn about RSPICE, consider joining the Melster Academy or book a personal meeting with me to find out how you can elevate your ASPICE expertise. I am looking forward to support your journey. Thank you very much for your attention. I will now hand it back to Sathiya and I will be happy to answer any questions you may have at the end of the webinar.
In this blog, we recap a section of our eBook, “The Clear Choice: Why Jama Connect Surpasses Codebeamer for Requirements Management and End-to-End Traceability” – Click HERE to read it in its entirety.
The Clear Choice: Why Jama Connect® Surpasses Codebeamer for Requirements Management and End-to-End Traceability
To adapt to increasing industry challenges and complexities, innovative organizations are now requiring best-in-class software to scale development, reduce risk, save time, and ensure compliance to quality, safety, and security regulations.
As organizations strive to deliver innovative products while navigating regulatory requirements, the tools they use for requirements management and traceability can make or break their success. This eBook is designed to help you understand the critical differences between Jama Connect® and Codebeamer, two leading requirements management solutions, so you can make an informed decision.
The Requirements Sector
The landscape of requirements management has undergone significant transformation. Traditional tools (like IBM® DOORS®) which once dominated the market, are now considered outdated. These legacy systems often lack the flexibility, ease of use, and integration capabilities required by modern teams. As a result, organizations are turning to modern solutions like Jama Connect that are built to meet the needs of today’s dynamic development environments.
Why Jama Connect?
Jama Connect stands out as a leading requirements management solution because it is designed with the user in mind. Its modern, user-friendly interface, combined with powerful features like comprehensive traceability and real-time collaboration, ensures that teams can manage requirements and risks effectively throughout the product, systems, and software lifecycle. Jama Connect also emphasizes customer success, offering expert support and training to help teams maximize their investment. Ease of use, rapid deployment, pre-configured well-documented industry frameworks, and in-house subject matter experts provide the fastest time-to-value/ROI without sacrificing quality or safety.
The Clear Advantages of Jama Connect Over Codebeamer
If you’re comparing Jama Connect to Codebeamer, one thing is clear — Jama Connect is the only purpose-built requirements management platform that delivers Live TraceabilityTM which allows engineering and other teams to
quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. In addition, Jama Connect accelerates your product, systems, and software development by managing user needs and product information across the end-to-end development lifecycle.
Only Jama Connect Delivers Live Traceability™ Across Best-of-Breed Tools
Other vendors lock you into inferior platforms. Only Jama Connect seamlessly integrates with your tools of choice across engineering teams. Only Jama Connect can manage the state of development across all integrated teams and tools. Jama Connect’s unique and industry-specific Traceability Information Models define the relationships and expected behavior across teams and tools.
Our customers consistently tell us that they chose Jama Connect over Codebeamer for the following reasons:
1. Ease of Use and High Adoptability
Jama Connect’s intuitive design and user-friendly interface make it easy for teams to adopt and use. Unlike Codebeamer, which can be complex and challenging for new users, Jama Connect ensures that teams can start managing requirements effectively with minimal training. Users insist on a requirements management and traceability solution that is easy to use so that both internal and external stakeholders can efficiently access, share, and review information in a single source of truth, increasing and speeding up the adoption across teams for a better ROI.
The ease-of-use is not only imperative for users but also for administrators. Jama Connect offers an intuitive and user-friendly administration interface that enables admins to adapt the tool to their organization’s needs without having to learn overcomplicated configuration settings and concepts.
2. Modern Integration and Collaboration Capabilities
Jama Connect provides comprehensive traceability and impact analysis, enabling teams to manage change effectively and reduce the risk of errors. The platform seamlessly integrates with other best-of-breed tools (including Jira and Azure DevOps) in the development ecosystem, ensuring that teams can work efficiently without having to change their other development tools. In contrast, Codebeamer focuses on working solely with other PTC tools and its own limited application lifecycle management (ALM) capabilities.
Modern product and software development requires optimal real-time collaboration between stakeholders. Jama Connect provides an enhanced collaboration experience with its communication streams and advanced Review Center, enabling both internal and external stakeholders with the capabilities to perform formal and iterative reviews.
3. Intelligent Engineering Management
Jama Connect empowers Intelligent Engineering Management by addressing a critical challenge faced by engineering and product development organizations: the lack of real-time KPIs and metrics during development. This gap often leads to delays, budget overruns, and product defects or recalls. Jama Connect uniquely transforms traceability into a measurable instrument, enabling teams to track real-time metrics and KPIs throughout the product development process. By providing a comprehensive overview of project progress and aligning it with required processes, teams can identify gaps early, mitigate risks, and avoid missed requirements. With its Live Traceability™ and integrations with other best-in-breed engineering tools, Jama Connect ensures that both internal and external data are seamlessly managed, driving informed decision-making and on-time project delivery.
4. Strong Customer Support
We know that our customers need a support team that makes them a priority. That’s why Jama Connect offers unparalleled customer support (including 24/7 support for any production outages), with dedicated customer success teams that work closely with you to ensure you achieve your goals. In contrast, Codebeamer’s support can be limited, making it difficult for your teams to get the help they need when they need it.
5. Scalable and Flexible
Jama Connect is highly adaptable, making it suitable for a wide range of industries and project sizes. Whether your organization is in automotive, aerospace, medical devices, or another industry, Jama Connect can be tailored to meet your specific needs, often getting you up-and-running quickly with custombuilt data frameworks to satisfy your industries regulations and best practices. Additionally, the platform offers flexible deployment options, including cloud and self-hosted, giving you the freedom to choose the best setup for your organization.
6. Fastest Time to Market/ROI
Deploy Jama Connect’s easy-to-use interface in weeks, not months, with easy updates and high performance. Preconfigured frameworks are built-in to satisfy industry regulations and help teams ease the path to compliance, along with in-house industry focused subject-matter experts and exceptional customer support.
7. Lowest Total Cost of Ownership
With simple and straightforward administration and no need for custom scripting or continuous updating, Jama Connect has the lowest total cost of ownership in comparison to Codebeamer. Jama Connect scales easily without big infrastructure investment, and with unlimited no-cost access for extended internal/external stakeholders, all team members can be involved with additional costs.
In the world of automotive and semiconductors, where the pace of technological innovation seems to accelerate daily, staying ahead of trends is critical. That’s why we sat down with Neil Stroud, Jama Software’s industry expert with decades of experience spanning major players like Intel, Arm, and Samsung. Neil has been at the forefront of the functional safety and semiconductor evolution, witnessing firsthand the challenges and transformative changes that shape these industries.
In this exclusive interview, Neil shares his unique perspective on the latest industry dynamics, the impact of global supply constraints, and how the automotive industry’s strategic relationships with semiconductor vendors are evolving. He also discusses Jama Software’s role in helping both sectors address increasingly complex requirements and integration challenges, driving efficiency and reducing risk across the supply chain. Join us in exploring how Jama Connect empowers companies to manage complexity, enhance traceability, and accelerate their time to market.
Driving Innovation: Quarterly Automotive & Semiconductor Trends with Neil Stroud
Kenzie Jonsson: Thanks for sitting down with me today, Neil! I’d love it if you could spend a little bit of time telling us about your background and career path.
Neil Stroud: Prior to joining Jama Software back in April of this year, I’d spent most of my career in the semiconductor industry, working for companies like Samsung, NEC, and PMC-Sierra. I also spent 12 years with Intel, and then moved into the IP space with Arm who are one of the key players in semiconductor IP. Directly before joining Jama Software, I spent time with CoreAVI, a niche software company in the safety-critical graphics space. Almost twenty years of my career has been spent in the functional safety domain. It wasn’t by design; it was more by accident. I didn’t set out to get into that domain at all. It all came about through my time at Intel where I was calling on a big industrial automation company and they asked me the question, “Hey, so when are you going to start supporting functional safety with Intel architecture?”
Of course, at that point, I didn’t know what it was, what it meant, what it was all about. One thing led to another, and I stumbled into the world of functional safety and was given a great opportunity at Intel to go… I was going to say, go and lead it, but it was more me volunteering and saying, I think we should be doing this. And Intel the senior leadership at Intel saying, “Oh, go on then, go do it.” That’s exactly what I did. So, it was quite nice because you’re acting as a startup within the safety of a big corporation like Intel. At that point you start to look at the fundamentals – what does safety look like? What do we need to do as a company? How do we sell it? How do we make money out of it? What are the technical issues? What problems are the industry facing? That kind of stuff. So, I pretty much became a GM of my own startup at that point, which was a great experience.
That was back in the day when complex semiconductor functional safety wasn’t really a thing. So, we were blazing the trail, not just for Intel but for the whole industry. So, little did I know back then where it would lead. It’s been so much fun. That’s also what took me to Arm – to drive the whole functional safety strategy across their ecosystem. So, all of that obviously led me into adjacent businesses especially automotive, as safety is of paramount importance where I worked with the big OEMs and throughout the supply chain. Now here I am at Jama Software bringing all of that experience of semiconductor, automotive, and software and apply that into the requirements management tools domain to drive our presence and growth in the automotive and semiconductor segments.
Jonsson: What changes have you been part of at Jama Software recently to help us better meet the needs of our customers?
Stroud: It’s a really interesting time to join Jama Software. Obviously, we’ve been successful as a company over the preceding years. I’m amazed by the number of different market segments that are using Jama Connect. There are some obvious ones like automotive, semiconductor, medical, consumer electronics, and aerospace and defense. But there are some emerging segments as well, which is great to see, like insurance companies and state departments and beyond. Clearly, Jama Connect is a tool that transcends verticals. But of course, we need to be able to tweak and tailor that to accommodate the unique needs of each market segment. Functional safety and cybersecurity are great examples of these differences. That’s what’s exciting as part of the change with Francisco Partners acquiring us back in April for $1.2 billion. That to me is a leading indicator that they’re betting on us to continue growing and we are investing heavily to continue to delight our current customers and of course help new customers achieve new levels of innovation. Placing that bet is exciting for all of us at the company. As a result, one of the changes we made at that time was to really double down on the vertical focus. So, bringing in an organizational structure that allows us to do and in turn drive even more alignment with the needs of each market segment.
It’s good for us. But more importantly, it’s good for the customers because we can talk in their language, we can better understand their problems, and of course we can partner with them to solve their problems. And that in turn means tailoring our product to better suit their needs. So, it’s a win-win. It’s a confirmation of the importance of those verticals to Jama Software and sends a clear message to that we are listening and here to partner with them on their growth journey. So, it’s exciting for me and I see that excitement across the whole company.
Jonsson: Can you tell us what you’re seeing in the industry with the conversations that you’re having with our customers and prospects?
Stroud: Well, I cover both automotive and semiconductor industries. There’s obviously a lot of overlap between the two, and I think that’s an increasing trend we’ve seen over the last few years. The automotive guys have been building a lot more of a strategic relationship with the semiconductor vendors. Not least because when the supply constraints kicked in a couple of years ago, production lines were coming to a halt because they couldn’t get hold of the smallest, tiniest, cheapest components. And at that point, it is interesting how it created a real forcing function. The automotive segment said at that point, “Right, we aren’t going to get burnt again.”
So, they did one or two things. Some went out and tried to tie down the semiconductor vendors contractually to say, “Look, in the event that this happens again,..” and it will happen again because the semiconductor industry tends to work on about a seven-year cycle of oversupply versus constraint, “we want to guarantee our component supply.” The car OEMs and tier-one suppliers obviously didn’t want to get caught in that again. I don’t have visibility into how successful those discussions were, but I don’t think it will necessarily prevent a recurrence. The good news is that there is huge investment going into building new fabs that will provide significant capacity increases in the coming years.
The other interesting dynamic that happened was some of the auto guys said, “Well, screw that. We’re going to do our own silicon.” It sounds easy when you say it quickly, but there’s an awful lot to it when you commit to that solution. Questions like, “Okay, so how are you going to do that?”, “Are we going to go and engage with a design house or we’re going to hire a team of semiconductor design engineers,” “Which fab supplier will we use?” “Will they guarantee supply?”
It’s not a trivial undertaking and to make it work from an ROI perspective it’s probably a ten-year journey. And in the meantime, you’ve still got to work with what you’ve got. The other issue is once you get down that path, you are committed and it’s an expensive commitment to make. The downside is you don’t get the benefit of volume that the big guys like Qualcomm, Samsung, MediaTek, or NVIDIA can offer you. They build millions and millions of chips and can amortize the cost across many customers and markets. If you’re building your own, you don’t get that advantage, but you mostly own your own destiny. So, pros and cons.
So that’s one dynamic. I think the other dynamic we’ve seen in automotive generally over the last five years is a repositioning of what’s important. If we go back, even just five years, we all thought we would be driving autonomous vehicles right now. There’d be mass deployment. You and I would both have one on the drive. Of course, that hasn’t happened because we all realized how difficult it is. I think we were in denial for a while, but that forced us to pivot to solving the software defined vehicle challenge. If we can get that taken care of, then that kind of leads us to the autonomous world anyway. And we can solve it in bite-sized chunks. So thankfully the automotive industry and the semiconductor industry, and probably lots of other industries now are focused on a software-defined vehicle as an intermediate step.
Solving this challenge doesn’t just apply to road vehicles. I think when you look at industrial automation, that’s the same. Do they want to get full autonomy? Of course they do. Is it a challenge? Yeah, it is. So, software-defined has a role to play there. Same in A&D, same in a lot of the other verticals. So, there are a lot of synergies between the verticals as well. That created, I think, clarity, but it also created a seismic shift for the car OEMs in that the OEMs themselves, and I’m talking more about the incumbent suppliers, the big guys like VW, Mercedes, Ford, GM and others. History shows they’re so used to being completely in charge of their own destiny – when you need something, you just put a team together and you go build it. Those days are gone. You look at complexity in a modern vehicle, whether it’s the hardware or the software, you just can’t do that these days. It’s not scalable.
So, you have to rely on the supply chain to drive the innovation and deliver those pieces, those elements, and then you as the OEM have to integrate them. But that’s not a world they’re used to. And it obviously introduces a whole world of complexity.
Stroud: That’s another area where using Jama Software really pays dividends to ensure the whole supply chain is seamlessly connected from a requirements perspective resulting in faster design and delivery across multiple vendors and a better-quality product overall. A modern vehicle can have upwards of 100 million lines of code going into a modern high-end vehicle and this is increasing exponentially. Those software elements are coming from a hundred different vendors. Some of those are safety-related, and some of those are security-related. All of a sudden as an OEM, I’m responsible for integrating all of that, checking it works together, checking it’s still safe, checking it’s still secure, and then rolling it out through the door for consumers to go and purchase a new vehicle.
At the same time, vehicle suppliers can use this new SDV approach to drive new business models that allow post-sales upgrades and updates. If a car doesn’t have a feature on the day of sale, in a year’s time the owner could say, “Hmm, it’d be nice to have that new feature.” You log into your account, put your credit card details in, and as if by magic, the new feature arrives over the air to your vehicle the next day. That’s a whole new world and we are only scratching the surface today.
So, I guess the punchline is from our perspective, and doing what we do, it’s all about efficient requirements management and traceability. This applies not just to the OEMs, but throughout the supply chain as well, to ensure the elements from those hundreds of different vendors all come together. Those requirements have got to be exquisitely accurate and all the independent interdependencies mapped out correctly to be sure that you’re not violating a safety goal or creating a bug in the system.
This way you get into traceability… How well is my project going? How healthy is it? How many of those requirements are covered right now and tested and using that capability to reduce the number of recalls, drive efficiency in the design team, reduce the risk, all those good things. Of course, this level of detail isn’t just important to the engineering teams. It can also be rolled out to senior management who are likely more interested in risk, cost, time-to-market and so on.
So, the market’s really coming to us. Jama Software is now the largest supplier of requirement management solutions overall, which we’re immensely proud of. But we have to learn from the market and our customers how Jama Connect changes grows and morphs as a solution to enable that ubiquitous risk reduction and efficiency improvement. So, there are some big factors at play.
We’ve done very well in the semiconductor space overall, but it still frightens me to see how many spreadsheets are used to manage the business in the big semiconductor companies. And that’s speaking from experience because I lived in that world for a long time. There are way too many spreadsheets out there for doing requirements tracking. When you’re working that way, there’s no single source of truth and that will get you into trouble, guaranteed. It will cost you big with bugs in the silicon. So, it’s imperative to partner with the semiconductor industry and really drive change, accelerate innovation and solve tomorrow’s supply constraints. That’s on the chip design side, but also more recently, we’ve got the CHIPS Act, which is kick-starting a massive investment in the semiconductor industry to drive fab capacity to meet the huge growth in demand for chips.
So, we see the big players such as Intel, Samsung, and TSMC, all investing billions and billions of dollars to put fabs into place to meet this growth in demand and technology, which is exciting. The challenges are different to the auto market but guess what, these chip manufacturers need robust requirements management to run their business. And again, a lot of it’s been running on spreadsheets for a long time.
Now, we’re seeing, of course, headwinds in both industries. We still see that with EV vendors on the automotive side. We see even today challenges in the semiconductor industry with some consolidation of cost and trying to get costs under control. Jama Software has a critical role to play in that transformation. We can help drive efficiency and shorten cycles and time-to-revenue. All those things play into huge cost reductions for all. We are using our expertise in both product and deployment to educate and drive incremental success for our customers.
Kenzie Jonsson: Thank you for your time today, Neil! I really enjoyed this conversation, and I look forward to catching up with you next quarter!
Tackling Industrial Manufacturing’s Biggest Challenges: Solutions That Work
Industrial manufacturing is undergoing a transformation driven by technology, market demands, and a rapidly evolving workforce. However, this evolution brings its own set of challenges that manufacturers must navigate to remain competitive. Below, we’ll explore the top challenges in industrial manufacturing and offer practical solutions to address them.
1. Supply Chain Disruptions
The Challenge: Global events like the pandemic and geopolitical tensions have exposed the vulnerabilities of supply chains. Material shortages, delays, and fluctuating costs have become routine, making it difficult for manufacturers to meet production targets.
The Solution:
Diversified Sourcing: Manufacturers should explore multiple suppliers, ideally in different regions, to reduce the impact of disruptions in one area.
Advanced Analytics and Forecasting: By leveraging data analytics, manufacturers can predict potential disruptions and adjust procurement strategies to maintain inventory levels.
Digital Supply Chain Management: Implementing technology like real-time tracking and automated inventory management systems ensures better visibility and responsiveness across the supply chain.
2. Talent Shortage and Skills Gap
The Challenge: As industrial processes become more automated and technical, there’s a growing need for skilled labor, particularly in areas like robotics, data analytics, and equipment maintenance. However, the industry faces a shortage of qualified workers due to retirements and a lack of interest from younger generations.
The Solution:
Reskilling and Upskilling Programs: Companies can invest in training programs for existing employees, focusing on emerging technologies and technical expertise.
Collaboration with Educational Institutions: Partnering with local schools and universities to create apprenticeship programs and internships can help build a pipeline of future talent.
Adoption of Automation: Automating repetitive or dangerous tasks can offset the impact of labor shortages while enhancing operational efficiency.
The Challenge: Industry 4.0 technologies, including IoT, AI, and machine learning, offer vast opportunities for improving manufacturing processes. However, integrating these technologies can be expensive and complex, especially for small and medium-sized enterprises.
The Solution:
Start Small, Scale Gradually: Manufacturers should begin by digitizing a single aspect of their production (e.g., predictive maintenance) and expand as they see ROI.
Cloud-Based Solutions: Cloud platforms offer scalable, cost-effective ways to implement Industry 4.0 tools without a significant upfront investment in infrastructure.
Cross-Department Collaboration: Ensure alignment between IT, engineering, and operations teams to facilitate seamless integration and minimize disruptions during implementation.
4. Meeting Sustainability Goals
The Challenge: Governments and consumers are increasingly demanding sustainable practices from manufacturers. This includes reducing emissions, minimizing waste, and adopting environmentally friendly materials. However, transitioning to green manufacturing can be costly and complex.
The Solution:
Energy Efficiency Audits: Conduct regular audits to identify areas where energy consumption can be reduced, whether through upgrading equipment or adopting renewable energy sources.
Circular Economy Practices: Embrace recycling and remanufacturing to minimize waste, both in production and post-consumer use of products.
Collaboration with Stakeholders: Partner with suppliers and customers to promote sustainable practices across the entire value chain.
5. Cybersecurity Risks
The Challenge: With the growing adoption of digital technologies comes an increased risk of cyberattacks. These attacks can disrupt production, compromise sensitive data, and damage a manufacturer’s reputation.
The Solution:
Regular Security Audits: Conduct frequent assessments of your digital infrastructure to identify and address vulnerabilities.
Employee Training: Train staff on cybersecurity best practices, particularly in recognizing phishing attacks and securing devices.
Robust Incident Response Plans: Develop and test response plans to minimize downtime in case of a cyberattack, ensuring quick recovery and damage mitigation.
The Challenge: Manufacturers are under pressure to produce more custom products, reduce lead times, and improve quality—all while maintaining efficiency. Meeting these demands often strains existing processes and resources.
The Solution:
Lean Manufacturing: Implement lean principles to eliminate waste in production and streamline processes, improving both speed and efficiency.
Automation and Robotics: Invest in robotic process automation to handle repetitive tasks, reducing human error and speeding up production.
Flexible Manufacturing Systems: Adopt systems that can easily switch between different product types, accommodating the increasing demand for customization without sacrificing efficiency.
Conclusion
Industrial manufacturing is facing unprecedented challenges, but with the right strategies and technology, companies can navigate these obstacles and position themselves for long-term success. From investing in workforce development to embracing digital transformation, the solutions are within reach. By proactively addressing these challenges, manufacturers can enhance their competitive edge in an increasingly dynamic market.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Steven Meadows and Kenzie Jonsson.
In this blog, we will preview a section from our video, “Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development” – Click HERE to watch it in its entirety.
Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle 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.
We are excited to introduce Florian Rohde, an expert in electrification, variant management, software defined vehicles, continuous integration and validation, and AI in automotive development. With more than 20 years of experience in the automotive industry, Florian has worked with companies large and small, from Siemens to NIO to Tesla Motors.
In this episode, we discuss:
Challenges in software defined vehicle development
Variant and configuration management in SVDs – and which companies are excelling
Balancing documentation, complexity, and speed
Below is a preview of our interview. Click HERE to watch it in its entirety.
The following is an abbreviated transcript of our webinar.
Kenzie Jonsson: Welcome to our Expert Perspectives series where we showcase insights from leading experts in complex product systems and software development, covering industries from medical device to aerospace and defense. We feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today I’m excited to welcome Florian Rohde, an expert in electrification, variant management, software-defined vehicles, continuous integration and validation, and AI in the automotive industry. With more than 20 years of experience in the automotive industry, Florian has worked with companies small and large, from Siemens to NIO, to Tesla Motors. Without further ado, I’d like to welcome Florian Rohde, who will be speaking with Matt Mickle, Jama Software’s very own director of automotive and semiconductor solutions.
Matt Mickle: Thanks, Kenzie. So my name is Matt Mickle. I run our solution development for automotive and semiconductor at Jama Connect. I’ve been with the company at Jama for about 11 years and worked as a consultant for most of that time. And now my team handles most of the consulting and development of solutions for automotive and semiconductor. And I live out in Europe, in Amsterdam. Came over here to help start up our European headquarters. And I’m joined today by Florian Rohde
Florian Rohde: Absolutely. Thanks, Matt. So I’m in the automotive industry for about 20 years. I started as an intern at Bosch, and then I started as a junior test engineer at a company called Siemens VDO, which then was incorporated into Continental. Back in the day, we were building electric power steering systems. So highly safety critical components in your car. So I got grounded into functional safety right from the beginning. I spent about seven, eight years at that company, both in Germany and in Romania. And then in 2012, I joined a startup called Tesla Motors, and that is bringing the interesting parts to our discussions here, I guess.
So in 2012, Tesla had about 2,000 employees worldwide. I was the first member and the founder of a team for vehicle software validation. So every software release, every software functionality on the vehicle level went through my signature for about six years. I counted over 700 releases in that time to the end customer and way more software that went through our test systems in that time. And after six years there at Tesla, I was one year at NIO as a director of integration of smart components. And starting 2019, actually, I became a consultant advisor all around SDV, software-defined vehicles, and basically trying to facilitate the communication between what you can call the old world and the new world. So the new players on the market and established 100-year-old OEMs because I speak both languages. I’ve been in both worlds. So I’m helping both sides, helping the new players really to understand regulatory things and scaling and things like that and helping the established players really to understand the role of software in today’s and tomorrow’s vehicles.
Mickle: Well, I know that when we started to talk about having this chat, one of the things that you’d mentioned is that you’re hearing quite often in the industry about challenges, especially as people are trying to shift into this modern way of working with software-defined vehicles. There’s still a lot of challenges around variant handling and configuration management. You have some strong background in handling some of those things, especially while you worked at Tesla. How would you say that your approach had to change when you started to think in a more software-defined vehicles perspective when it comes to variant management?
Rohde: Yeah. I think in general, there’s a lot of challenges. Variant management is one of them. But I think let’s focus on that for the purpose of this talk. Let’s not focus on engineering culture or software skill sets and so on. That’s, for sure, other topics we can talk about. But today, let’s talk about variant management, configuration management, etc. So on one hand, I see gigantic numbers of configurations out there when you look at legacy OEMs. And somebody told me just Ford F-150 numbers, they were like hundreds of thousands or even higher than that. So on one hand, you see the companies struggling with the variety of variants actually of their product. But then on the other hand, you also see R&D teams struggling with those variants, both in how to handle them on the development side of things, but even more so on the testing side of things, especially… So I’m a test engineer, originally. And for test engineers, additional variants are usually a nightmare because it just means basically one-on-one growth of your testing efforts.
So there is a problem that needs to be solved and it’s on two sides. It’s one, how do you solve that problem in your product itself? And the other thing is, how do you solve that problem in your tool chain? So things like what you’re doing on the requirement side of things, specification, and so on. Let’s look at the product for now. So Tesla had a different approach to this problem. They actually made themselves agnostic to the variety of variants. What does that mean? That means they developed their product software first and they were designing the software in a way that it can handle pretty much an endless amount of variance. Of course, and we can talk about that, there’s challenges to the validation of things. There’s challenges to how you handle software updates. There’s challenges how you handle releases. But we had a pretty good process in place to do so. But the alpha and omega of the whole thing is that there’s a system in place that allows the software to handle the variance without being handcuffed to some process from the past.
Mickle: Okay. So a lot of the challenges that I hear, and maybe some of what you hear, is especially around the alignment of the software with the hardware in terms of releases, considering those are evolving at different paces. So since the software is evolving so fast and handling multiple configurations, how do you account for that with what you’re doing with either tooling or the product?
Rohde: Right. So I think there’s a consensus in industry by now that the hardware has to be able to accommodate new software features over time. Or in other words, it has to be designed for a little more than it originally offers at start of production. There’s still a lot of hesitance around legacy carmakers because it’s a financial discussion, right? So I don’t think from technical point of view, anybody would disagree that the hardware should be overdesigned by, let’s say, 20% so the software can start evolving over time and creating new cool stuff. But it’s always a question how you actually finance that.
The good news here is that actually, hardware and compute power becomes more reasonable in pricing. So we’re not talking about dollars per bytes in memory anymore. We started talking about dollars per gigabytes, right? So we can actually make that happen a little easier. But obviously, there’s a strong legacy of hardware driving the timelines, and then the software goes on the hardware to make the functionality work as designed and then go into the car as a component. So now in the next generation of cars, you hear a lot the term of decoupling. So you’re decoupling software from hardware. What does that actually mean? That means that on the technical side of things, you have to find ways to have your software actually handling the car’s compute resource and not as a conglomerate of several separate ECUs. So we’re talking about zonal architecture at one point in the future, we’re talking about high compute power architecture, HPCs.
But on the other hand, it also means organizationally and structurally. So when I go back and look at the Tesla example, Tesla has one software that runs on all their cars. And the cars are, for sure, not all the same hardware. As a matter of fact, I like to sparkle that in here right now because a lot of people think Tesla holds the variance low, but that’s not the case. Yes, they have only four or five models in the field, five actually by now. But they actually perform some sort of a facelift statistically every week. So while in a traditional car-making you wait for about three to four years before you put in a flurry of hardware changes, and in between, the car stays more or less unchanged. What we experience at Tesla is that every week, there’s some new hardware going into the car. So there’s some new costs down available. There’s something better available. There’s some replacement parts available. It goes in right next week. And that means that you have thousands and thousands of different variants of Teslas driving out there, even though from the outside, they all look the same.
So what we did is we decoupled the software in a way that it’s “smart enough” to handle all these variants. So the way that works is there’s a package and that package of software contains all different options and variants, and it also contains the information who is allowed to play with who, so what variant is allowed to play with what variant of the other car component and so on based on our validation and release process.
But in general, in a very simplified way, the car knows what it is, and that’s already a huge difference to a lot of legacy carmakers. So the car has a digital information about its components in hardware and in software and in mechanics. And based on that information, it receives the software package and it builds its own personalized update out of that. And it’s talking to the components and updates the components with the right versions based on the information it has. This information is on the other hand also mirrored up into what they call the mothership, so the server area. So that information is available in real-time, and I’d like to talk about that a little bit because I think it’s extremely valuable, for example, for the validation and release process to set your priorities.
So let’s say I only have time to do one combination. So I would like to reach most people with my release today. Of course, I’ll do the next combination tomorrow and the day after. But today, I have only time for one and I want to reach the most people. So I can go and I can actually look what combinations are out there that are relevant for this release and I can prioritize my validation on that. Actually, at one point, we went so far that we even took time zones into consideration that we say, “We can validate all of this large area of the fleet, but hey, that will be midnight or 1 AM by the time they get it. So they will not install it for another eight hours or something like this. So let’s focus somewhere else.” So all this information is making it extremely powerful to manage your priorities and both in research… Sorry. And both in development and in validation.
By leveraging Jama Connect, DoD systems development teams can significantly improve their efficiency, reduce risk, enhance safety, and expedite development while maintaining the highest standards of regulatory compliance with MIL-STD- 882E, contract requirements, defense data standards, interface standards, design criteria standards, manufacturing process standards, standard practices, and test method standards.![[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing](https://www.jamasoftware.com/media/2024/03/Key-Systems-Engineering-Skills-Critical-Thinking-and-Problem-Framing.png "[Webinar Recap] Key Systems Engineering Skills: Critical Thinking and Problem Framing")
