Jama Connect® Supports Export-Restricted and ITAR Use Cases
Organizations operating under export restriction and/or International Traffic in Arms Regulations (ITAR) face unique challenges when selecting collaboration tools for product development. These regulations, designed to control the export of defense-related articles and services, require stringent data handling and access controls that many standard software platforms cannot accommodate.
Jama Connect provides a robust foundation for export-restricted and ITAR regulated environments through its comprehensive security architecture and flexible deployment options. However, successful ITAR-compliant support requires a shared responsibility model between Jama Software and our customers, with each party maintaining specific obligations to maintain regulatory adherence.
Organizations using Jama Connect for ITAR-regulated projects must implement specific deployment and operational practices to maintain compliance.
Deployment Architecture
Self-Hosting Requirements: Customers must deploy Jama Connect on their own ITAR-compliant infrastructure or utilize specialized partners like Vantage ALM for GovCloud deployments. This ensures the customer’s complete control over data location and access pathways.
Infrastructure Security: Organizations are responsible for ensuring the security of the underlying infrastructure, including network controls, server hardening, and physical security measures.
Data Handling Protocols
Information Segregation: Customers must ensure that ITAR data remains isolated within their controlled environment and is never transmitted to Jama Software through support channels or email communications.
User Access Controls: Organizations must implement and maintain proper user authentication, authorization, and regular access reviews to ensure only qualified personnel can access ITAR-controlled information.
Jama Software Responsibilities
When supporting customers in export-restricted or ITAR-controlled environments, Jama Software maintains specific operational protocols to respect regulatory requirements while providing necessary technical assistance.
Meeting and Communication Protocols
U.S. Person Verification: For any customer-requested meetings or working sessions involving discussion of ITAR restricted information, Jama Software will confirm that all attending personnel are ITAR Accessible Persons currently located within the United States upon the request of the customer. The customer must give Jama Software prior notice so that we can arrange the proper personnel to attend such calls.
Documentation Restrictions: No recordings, screenshots, or other documentation will be created during these designated ITAR support sessions to prevent inadvertent data capture or storage.
Write Clear Design Inputs: A Practical Guide to ISO 13485 Compliance
In the medical device industry, the clarity of your design and development inputs is vital. Unclear or conflicting requirements can slow down development and make it harder to meet regulatory expectations. This session offers practical guidance to help ensure your design inputs are clear, complete, and fully aligned with ISO 13485 standards.
In this webinar, industry expert Peter Sebelius, CEO and Trainer at Medical Device HQ, shares proven strategies for writing effective requirements. Discover how to avoid common mistakes and build a strong foundation for compliant, successful product development.
Key Takeaways:
Identify and steer clear of the most common mistakes in requirements engineering, using real-world examples.
Learn straightforward techniques to make your requirements clear and organized.
Put proven patterns to work so your documentation is complete, audit-ready, and easy for all stakeholders to understand.
Understand ISO 13485 expectations so your design inputs are unambiguous, verifiable, and consistent.
Walk away ready to write clear requirements and robust design inputs that stand up to ISO 13485 audits and set your team up for development success.
WEBINAR VIDEO PREVIEW BELOW – CLICK HERE FOR ENTIRE PRESENTATION
Tom Rish: Thank you for joining us today with today’s webinar on How to Write Design and Development Inputs. We’re very excited for today’s speaker, Peter, and I’ll give you a proper introduction to him here in a few minutes, but I want to cover a few housekeeping things about the webinar platform.
First off, my name is Tom Rish. I’m the head of vertical marketing for the medical device and life sciences group at Jama Software. I’m very excited to introduce our speaker, Peter Sebelius. Peter is one of those rare people who can take something very complex like medical device regulations, product development, and make it understandable. He’s a highly respected trainer, consultant, and entrepreneur in the medical device industry. And one of the most exciting things for all of us here is he’s a member of the joint working group that authored the latest versions of ISO 13485 and ISO 14971 standards. So you don’t get very many chances to interact with somebody who has that much influence on the regulations.
One of the things I love most about Peter is he’s known for his clear no nonsense explanations, very practical teaching style. I think one of my favorite things is to find a post on LinkedIn that I sometimes think, “Oh, I don’t know if I fully agree with that.” And usually if I go to the comments section, I see Peter there correcting it and I always enjoy reading those. He speaks for what’s true and that’s great in this industry.
His focus areas are design controls, requirements engineering, risk management. I’ve actually had a chance to take one of Peter’s courses myself in the past. It was the risk management course and I’m very grateful for that. I was about years into my career, actually. I wish I would’ve taken it earlier. Many of you in this industry, if you’re like me, had a bunch of binders plopped on your desk on your first day and said, “Read through these regulations.” And unfortunately, that doesn’t really teach you enough about what you need to do to do things right. That risk management course was amazing and I learned a lot about how to do it the right way. If I was leading a new medical device project right now or had a team of people, whether young or old, I highly recommend taking some of Peter’s courses.
And on that, his courses, Peter is the founder of Medical Device HQ, which is this company that we’ll hear more about on the next slide. And Peter has a great team behind all of the training courses that they deliver. What makes them stand out specifically is they’re created by ISO and IEC standards committee members, so very impressive, important people providing practical application, not just the theory behind it, which I think so many of us get exposed to, but actually how to do it. They offer fantastic resources in the form of articles and YouTube videos. Check out their YouTube channel. If you go to YouTube, it’s just Medical Device HQ. Their training cover a lot of topics ranging from design controls, requirements engineering, risk management, usability. I know I’ve seen the ISO 13485 on quality systems as well. So there’s a training for about everything. You can do it online, you can do it in blending formats with live classroom sessions or even through your company’s LMS. We’ll include a link to all of those courses in their website and a follow-up email after this webinar.
So with that, I’d like to hand it over to Peter. And thank you for being here, Peter. We’re excited to learn more from you.
Peter Sebelius: Thank you so much for that introduction, Tom. It was a pleasure. So let’s get to it. In this session, I’ll be showing you how to write unambiguous design and development inputs and meet ISO 13485 requirements. One of my first questions to you is really are requirements important? Well, yes they are. Now, studies have shown that the root cause of a lot of nonconformity and quality problem would be poor requirements. Now, one thing about the medical device industry that makes me really sad is that many medical device organizations, they work with requirements not because they see the value in it, but because they have to. And this I would say is a general problem in our industry. Too many organizations do what’s required without knowing why and without seeing the value, it’s compliance above quality, which I think is a very sad or odd way of looking at things.
So I hope that after this webinar you will believe in the value of writing good requirements, but if you don’t and you’re entirely focused on compliance, should you then be paying attention? Well, yes you should because if you take a look at sub-clause 7.3.3 in the ISO 13485 on design and development inputs, you can see that your design and development inputs or requirements shall be complete, unambiguous, able to be verified or validated, and not in conflict with each other. Now, if you don’t know what these things mean, trust me when I say not many do, you are at risk of getting non-conformities. And luckily, for those who don’t know the meaning of these characteristics, not many auditors do either. Only in some cases are auditors likely to react if your requirements don’t fulfill these characteristics. And that is one of the reasons why I created a pretty unique course on requirements engineering for medical devices on Medical Device HQ, because I’ve seen that there are very few who knows this area in the medical device industry.
So what you will be seeing today are some highlights from this course. If you’re interested in learning more, you are obviously very, very welcome to register on the full course, which is much more comprehensive than what we are looking at today. So during my training courses, I often ask how many of the participants have participated in risk management? And then I ask, how many of you have formal training or risk management? And usually about 90% would say that they are involved in risk management and that they have some kind of training. And then I continue to ask, how many of you have been involved in writing requirements? And it’s almost as many as in risk management. Then when I ask how many have formal training and requirements engineering? And when I say training, I don’t mean read and understood. That doesn’t count. Like Tom’s reference, read all the binders. That doesn’t count as training if you ask me.
Now, what do you think happens when I ask about that? Well, it becomes very silent. It’s less than 5% who says that they have some kind of training on writing requirements. And that’s really unfortunate because writing requirements is a critical task if you want to be successful with product development and medical devices, it’s the foundation. But not only that, if you don’t know what you’re doing in this area, it also creates lots of frustration and conflicts between the team members and then you’re wasting time. And I really dislike wasting time. I think we should be bringing medical devices to market as quickly and as efficiently as we can because every new medical device should be an improvement compared to the previous ones, which means if we are wasting time, we’re depriving the public of better healthcare. And that’s unethical, believe it or not.
Now, this task, the writing requirements requires both knowledge and skill to be done correctly and successfully. Now, before getting to how to write good requirements, let me talk about two more pain points in the area of requirements engineering in the medical device industry and let me know if you agree and you recognize any of these issues in the chat. And like Tom said, we appreciate if this is interactive. So if you say yes or you’ve seen exactly this, do share it in the comments. That just makes everything nicer and more attractive. So the first pain point is that requirements end up in the wrong processes. It could be that you find design outputs together with the design inputs or you find risk controls that are documented as user needs. There are so many mix-ups, and when you try to push the various types of requirements through the wrong processes, it’s utterly confusing. It could even result in non-conformities and it will not work well. And I will come back to why.
Unlocking the Power of Jama Connect Interchange™ and MathWorks Integration
Keeping requirements and engineering tools in sync is crucial for effective product development. In complex product development, connecting requirements management with engineering tools is crucial for success.
When teams work in disconnected environments, the risk of errors and compliance gaps grows. An integration between Jama Connect Interchange™ and MathWorks tools like MATLAB and Simulink bridges this divide, creating a seamless, bidirectional flow of information. This connection ensures every team member, from system architects to design engineers, works in alignment with the most current data.
This powerful integration offers significant benefits that streamline development cycles and improve product quality. By automating the exchange of requirements and design data, teams can achieve greater efficiency and collaboration.
Key advantages include:
End-to-End Traceability: Create a clear, auditable link from high-level requirements to detailed model elements.
Reduced Errors: Minimize manual data entry mistakes and miscommunication between teams.
Streamlined Collaboration: Enable systems and design engineers to work together effectively in their preferred tools.
Time and Cost Savings: Automate processes to shorten development cycles and allow teams to focus on innovation.
WATCH THE FULL DEMO BELOW
VIDEO TRANSCRIPT:
Patrick Garman: Hello, my name is Patrick Garman. In this demo, I’m going to walk through an example of using Jama Connect Interchange to share requirements with MathWorks tools, then bring that information back into Jama Connect® for complete traceability. Here’s what you’ll see.
First, I’m going to export a set of requirements from Jama Connect to a ReqIF file using Jama Connect Interchange. Next, I’ll import that ReqIF file into the requirements editor in MATLAB and link those requirements to model elements in Simulink. Once those links are in place, I’ll use MATLAB’s native ReqIF export feature to create a new ReqIF package that includes both the requirements and their Simulink connections.
Finally, I’ll import that ReqIF file back into Jama Connect using Jama Connect Interchange, which will update any requirements that were edited in MATLAB, and also create a new set of model items in Jama Connect to represent the Simulink model elements.
By the end of this process, you’ll see how Jama Connect maintains end-to-end traceability between requirements and model elements, bridging the gap between systems engineering and model-based design. So here I have a Jama Connect project, and you see I have a set of functional requirements here. And these are some requirements that I want to link to elements of a model that I’ve built in Simulink. And I’m going to start this process by exporting these requirements into a ReqIF file. And ReqIF file is essentially an XML file type, but it is a format that is specifically designed to be a standard file type for requirements management tools to enable this kind of exchange of information.
Garman: All right, so I’m gonna start. I’ve already connected my Jama Connect instance to my Jama Connect Interchange. And so I’m going to come to our conversations page, and I’m going to start a new conversation. Just gonna give it first, I need to tell it what tool I’m going to be connecting with, and so we’re going to go with Simulink. And next. And then we need to pick if we have more than one Jama Connect connector, we’ve gotta tell it which one we want to export and import with, and then we just need to pull the project ID. So here we can see this is project two fifty one. So I can search by project using the API ID, or I can use a text search using this drop-down menu.
So this project is a Simulink demo. There we go. Just type a few letters. It pops up for me. And then I’m gonna give my conversation a name, and this is how I can know if I’m having several projects or even several sections of a project that are exchanging information with Simulink. We want to have separate conversations for those. So now I’ve created the conversation space in Jama Connect Interchange, and I want to start by exporting. So I’m gonna come to my export page. And here, I’m gonna start by selecting a location.
Step one: Location. There are a few different ways that our locations can export a baseline. For this situation, I’m going to stick to the container and I’m going to select my functional requirements, even that set of. So I need to select either the project root or a component, and I’ll have a chance to filter items out. But here, I’m gonna select this component and click next. And within that, if there were other sets of items, I could filter those out, but this is the one that I want. So I’m going to save.
Now then, on export, there is field mapping that I can select. For example, if I had more than one item type, more than just functional requirements, I could select which item types I want to include. But I can also set which fields I want to keep for each of these. So there may be several fields that I just don’t care about bringing into MATLAB Simulink because they’re not relevant to the work that I want to do there. Or I just don’t need them and that other thing. So I can turn off any of these fields that I don’t care about or don’t need to have in in Simulink. So I’m only exporting the specific data that I want to import into Simulink.
Alright, so in this case, I’m really just keeping the name, description, and rationale fields. So I can save that export mapping, and Jama Connect will also capture all of your relationship types just in case we again we’re pulling the relationships back in, but those are all mapped automatically. So from here I can just initiate export. And confirm. And depending on how many items this is, you know, six or seven items, it’s going to be really fast. Depending on how many items you are trying to export into ReqIF, that could potentially take longer. But from this log screen, can see the progress, especially if you use the funnel icon, include debug, it brings in, it gives you some status, but ultimately, it gives you this link where you can download the ReqIF file. So here, I’m just gonna drag and drop that onto my desktop so I can find it. And now I’m going to switch over to MATLAB. So starting here in Requirements Editor, because I need to import those requirements that I did previously. Here, I’m gonna delete. So for that, I’m going to first clear out what I had done previously. I can’t do that. So I’m just gonna import. We are importing from ReqIF, and I’m just gonna browse to find the file that I saved to my Desktop.
Garman: So here we have that ReqIF I just created from Jama Connect. So we’ll open that. In these other settings, MATLAB automatically selects some things. I would say, you know, it automatically detects that it’s coming from Jama Connect. If you want to save this in a different location, you can do that here. Ultimately, we’re going to import these requirements. Alright. So here I have my second import, and you can see that these requirements have come through. Now then, I export the description rationale field. So why are they not showing up here? Because this is the MATLAB description and rationale field. For those Jama Connect elements, we need to come down here to custom attributes. And here we can see all of those, all of those fields as set that we exported. Alright. Now that we’re in MATLAB, this is our model that I want to start connecting things to. So in MATLAB, I’m going to select a model element here at the controller. And we will say that one point one is the one, so I can just right-click it and link from the controller. And I could even say, here we go, my Dryden Wind gust models are part of one point three. So again, I can create the link there. And let’s do one more. Let’s do this small gain one. We’ll link that to one point six. Okay. So now we’ve made we’ve added all of our links And and so now what we want to do is we want to take what we’ve done, I want to save it, but then I’m going to export this back to ReqIF.
Here, I can just reuse the original mapping from Jama Connect. If there are, you know, attributes that you want to remove, you can do that here. But the most important thing is we want to export links. So make sure that this export links box is checked, and then we can set a location. I’m gonna move this to our desktop again for easier finding. When we’re ready, we can just click export. So it’s running through everything. It’s gonna save that to our desktop. So, what we can do now is let’s come back to Jama Connect Interchange, and I’m going to switch to import because now we’ve pulled that data from MATLAB and Simulink and we want to bring it into Jama Connect. So I’m gonna go to my import in the same conversation. Click upload.
I’m gonna select that file that I just pulled out of Simulink. And we’ve already set the location, which we can edit if we need to, but we’re gonna leave it at the same location. And here we’re gonna map for the import. So we want to have our functional requirements mapped back to functional requirements in Jama Connect. And these others, these are those model elements that we want to bring back in. And so I’m gonna bring those in as Models. So I can select what item type in Jama Connect I want to have as a reference to those elements back in MATLAB Simulink. So I’ve turned those on. Now I’m gonna, oops, save our item type mappings. And I can switch to fields. And here, the same thing. I just want to map everything back to what it should be in Jama Connect. So here, I’m looking at those model elements. So we want to create this as a set. And we want to bring in the name of the set to the or the name of the collection from MATLAB to a set name in Jama Connect. But then we also have to establish these object types. So here are just Simulink objects. If we had, say, headers or information items, we could maybe map those differently. But we want to tell Jama Connect the Simulink objects should be brought in as folders, text, or models? And in this case, that’s the actual model elements. So we’ll bring them in as models, which is the item type that we map to in the first step.
So now Jama Connect is going to generate the mapping. So we are gonna pull here are the elements, the metadata elements that are found on these Simulink objects, and we just wanna map these back to an item in Jama Connect. So here description will go to description, name goes to name. And if we want to keep if there is a, you know, key, we could map that to an additional field. But once we’re done, we’re gonna click save.
Garman: Now we will move on to our next item type, which is functional requirements. And, again, functional requirements will come back in as a set. And we really only have to map those fields that we want to update. So here I can just leave that as a name, and here a functional requirement. We’ll go back to the functional requirement. And, again, we really don’t have to map many of these fields back if we’re not actually bringing in field-level updates. So here, I’m just gonna map the name. If I had made changes to the other fields in MATLAB, I would change those here. And the final step, I wanna go to relationships, and I just need to map these back into the appropriate even though they’re originally pulled from Jama Connect, and mapping them back to the relationship types that they were pulled from. The good thing about doing this import mapping is that you really only have to do it once. Once you’ve mapped everything in this conversation, you can just keep reusing this conversation and make updates as necessary.
Okay. Another thing you’ll notice with each of these relationships, have this option to reverse direction. And there, that is because some tools treat traceability in a slightly different direction. So, what is happening right now in Simulink, the way I created those is that the model element is actually upstream of the requirement. But in Jama Connect, we want the requirement to be upstream from the model. So I can just I can fix that by clicking this box to reverse direction. On each of these so that when it brings it in, they will be in the correct the relationships will be in the correct cardinal direction. Alright. So once we’ve done that, we can click save.
And now that we’ve mapped everything, we can initiate import. And Jama Connect is gonna ask us, “Do we want to update existing items?” And that’s what we want to choose for this, because we want to update the existing functional requirements, and those model elements will be brought in as new items. Now then, in future iterations, if we export these functional requirements and these model elements into Simulink again, say we’ve made updates, we want to redo it again, it’ll update the existing models that you’ve already imported. If you select create new items, it will only create new items. It will not update any existing items. So in this situation, I want to update the existing items. So we’ll confirm. And tells us to take a look at the logs page, and it’ll take a little bit for this to finish. So again, we’ll get a complete message when it’s done. But if we want to see more, we can enable this debug option.
And you can see that Jama Connect Interchange is evaluating, and it’s saying like, “look, no field changes happened” with these, so we’re not going to update those. But here we go. We do have a few fields that we had to update, and we’re creating those relationships because again, we linked three items. All right, so let’s go back into Jama Connect, and if I refresh my tree, you see that there’s this additional component here under my functional requirements. If I expand that, I have this set of models. And then here I have each of those models. So here is the controller. And you can see it has a link back to that element, the description field. And it is related to the transfer history with a “Satisfied By” Marker.
And that concludes the demo. You’ve now seen how Jama Connect Interchange makes it possible to seamlessly exchange requirements with MATLAB and Simulink through the ReqIF standard. By moving requirements into MATLAB, linking them to model elements in Simulink, and then bringing those links back into GeometConnect, we’ve established full traceability between the system requirements and the model-based design. This integration helps your teams reduce errors, streamline collaboration across engineering disciplines, and maintain compliance with industry standards. Thank you for watching, and please reach out if you’d like to explore how Jama Connect can support your development process.
An Inside Look at the Airborne Fire Control Radar Market: The Sky’s AI
These days, air superiority isn’t just about speed and firepower; it’s also about data and information. At the center of this data-driven battlespace is the Airborne Fire Control Radar (AFCR), a cutting-edge system that gives pilots unparalleled situational awareness. The AFCR systems on an aircraft act as its eyes and brain, enabling it to track, detect, and engage targets with remarkable accuracy from a considerable distance. They have a significant impact on the outcome of aerial engagements and the effectiveness of combat aircraft, making them vital to military aviation.
This blog will examine the ever-changing AFCR market. We’ll look at the current developments that are fueling its expansion, such as evolving geopolitical environments and technological advancements. The main participants in the industry, their difficulties, and the prospects for this crucial defense technology will also be discussed.
What is an Airborne Fire Control Radar?
Military fighters, bombers, and attack helicopters are the main aircraft equipped with the advanced sensor system known as an Airborne Fire Control Radar. An AFCR offers the high-resolution information required to direct weapons to a target, in contrast to conventional surveillance radar, which merely detects objects. It provides the aircraft’s fire control computer with the target’s range, altitude, speed, and trajectory. This enables the pilot or system to fire cannons or launch missiles with a high chance of hitting a target directly, even if the target is moving quickly or evasively.
It is impossible to exaggerate the significance of these systems. They enable a single aircraft to engage multiple threats at once, monitor large areas of airspace, and discriminate between friendly and hostile forces. To put it simply, an air force that has a better AFCR system has a clear combat advantage.
Current Drivers and Trends in the Market
A number of important factors are propelling the global AFCR market’s steady growth. The main drivers are global air force modernization and geopolitical tensions. Countries are investing in new-generation fighters with cutting-edge technology and updating their current fleets of aircraft with more sophisticated radar systems.
The primary force behind change in the AFCR market is technology. There are two noteworthy developments:
AESA Radar Dominance: The industry standard today is Active Electronically Scanned Array (AESA) radars. Because AESA systems can electronically steer their beams, they can track multiple targets in different directions simultaneously, unlike older mechanically scanned radars. They are essential for contemporary air forces because they are more dependable, more difficult to detect, and more resilient to electronic jamming.
AI and Cognitive Radar: “Cognitive” radars are being produced by combining machine learning and artificial intelligence. These systems have the ability to learn from their surroundings, adjust in real time to new threats, and more accurately separate targets from clutter. By lessening the pilot’s workload and accelerating decision-making, this technology has the potential to completely transform air combat.
Increasing Need for Unmanned Systems
A new area for AFCR systems has been made possible by the widespread use of Unmanned Aerial Vehicles (UAVs), also known as drones. Sophisticated, portable radars are necessary for advanced combat drones to conduct autonomous missions and surveillance. Compact and effective AFCR solutions designed for UAVs will become more and more necessary as their use in military operations grows.
Obstacles in the Market
The AFCR sector still faces many obstacles in spite of its expansion. These difficulties may affect development schedules, expenses, and the general growth of the market.
High Costs of Development and Production
The complexity of AFCR systems necessitates years of study and billions of dollars in funding. They are costly to manufacture and maintain because they require sophisticated electronics and exotic materials. The potential market size may be constrained by these exorbitant expenses, which may act as a deterrent for smaller countries seeking to update their air forces.
The export of sophisticated AFCR systems is strictly regulated since it is a vital military technology. To keep sensitive technology out of the wrong hands, governments enforce stringent regulations. Market expansion may be slowed by these export restrictions and international arms control laws, which can make international trade and cooperation more difficult.
Complexity of System Integration
One of the biggest engineering challenges is integrating a new radar system into an existing aircraft. Aircraft hardware types and avionics interfaces differ from manufacturer to manufacturer, creating interoperability challenges. For the radar to function flawlessly with the aircraft’s other avionics, mission computers, and weapon systems, significant hardware and software adjustments are needed. Program upgrades take longer and cost more because of this complexity.
Prospects for the Future and New Technologies
With ongoing innovation poised to unlock new capabilities, the AFCR market appears to have a bright future.
The shift to multifunction RF systems is among the most exciting developments. Future aircraft will use a single, integrated aperture that can do all of these tasks at once, rather than having distinct systems for communications, radar, and electronic warfare. This will significantly increase an aircraft’s capabilities while decreasing its size, weight, and power consumption.
The creation of distributed and networked radar is another expanding field. This idea uses real-time radar data sharing between various platforms, including fighters, drones, and satellites, to produce a single, complete image of the battlespace. This networked strategy increases the effectiveness and survivability of all friendly assets and makes it nearly impossible for an adversary to hide.
In conclusion, a market ready for innovation
A key component of the contemporary defense sector is the market for airborne fire control radars. The need for more capable and intelligent radar systems will only increase due to technological advancements and the ongoing requirement for air superiority. Despite ongoing regulatory obstacles and exorbitant costs, the industry is progressing. The sky’s eye is growing more potent than before with the introduction of AI-driven cognitive radars, multifunction systems, and networked capabilities, giving pilots the advantage they need to manage the air.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Mario Maldari, Cary Bryczek, and Decoteau Wilkerson.
How to Master Traceability in Medical Device Development
As an engineer in the medical device industry, you’re tasked with creating innovative products that are both safe and effective. However, this core mission is often overshadowed by the immense pressure of regulatory compliance and documentation. As technology advances and products get more complex, that task gets even more complicated. Managing traceability between thousands of requirements, risk items, and test activities can feel like a “paperwork” burden that pulls you away from what you’d rather be doing: designing and testing new products.
This article offers a practical guide to transform traceability from a time-consuming chore into a strategic advantage. We’ll explore how to build a robust traceability model that not only satisfies regulators but also helps you build better, safer products faster.
TL;DR: Stop treating traceability as an end-of-project scramble. By implementing a single source of truth with Live Traceability™, you can connect requirements, risks, and tests in real-time. A modern platform like Jama Connect® automates this process, helping you identify gaps early, reduce rework, and free up your team for more efficient product development.
The High Cost of Inefficient Traceability
When traceability is managed with disconnected documents and spreadsheets, it becomes a significant bottleneck. This manual approach is not just inefficient; it introduces substantial risks that can derail a project and kill the team’s morale. For complex medical devices, the consequences of poor traceability are severe:
Project Delays: Manually creating and updating traceability matrices consumes hundreds of hours, often at the end of a project that results in pushing back launch dates.
Compliance Risks: Incomplete or inaccurate traceability is a common reason for audit findings and can jeopardize FDA submissions and technical file reviews under the EU MDR.
Increased Rework: Without a clear line of sight between requirements and tests, design changes can have unforeseen impacts, leading to costly rework late in the development cycle.
Reduced Innovation: Engineers spend valuable time on administrative tasks instead of focusing on design, testing, and innovation.
The key takeaway: Treating traceability as a final-step documentation exercise is a high-risk strategy. The true cost isn’t just the time spent on paperwork, but the project delays, compliance failures, and missed opportunities that result from it. You can assess your own risk by taking a Requirements Traceability Diagnostic.
How-To: Best Practices for Ensuring Medical Device Traceability
To move from a reactive to a proactive approach, you need to integrate traceability into the fabric of your development process. Here are four actionable steps to make that happen.
Step 1: Establish a Single Source of Truth
The foundation of effective traceability is a centralized platform where all product development data resides. When requirements, risk analysis, and test cases live in a single system, you eliminate the confusion and errors caused by separate documents.
A single source of truth ensures that every team member—from systems engineering to quality assurance—is working with the most current and approved information.
Benefit: Creates consistency and provides a complete, auditable record of your design history.
Impact: Reduces miscommunication and errors, ensuring all teams are aligned.
Step 2: Implement Live Traceability™
A static, manually created traceability matrix is outdated the moment it’s finished. Live Traceability, in contrast, creates a dynamic, real-time map connecting every requirement to its corresponding risks and test cases.
With Live Traceability, you gain instant visibility into the health of your project. If a requirement changes, you can immediately perform an impact analysis to see which downstream requirements, risk mitigations, and test items are affected.
Benefit: Allows you to identify and address gaps in coverage early in the process.
Impact: Drastically reduces audit preparation time and minimizes the risk of missing critical connections.
Step 3: Integrate Risk Management into Your Workflow
For medical devices, traceability isn’t just about connecting requirements to tests; it’s about proving that every potential hazard has been identified, analyzed, and mitigated. This is a core expectation of standards like ISO 14971.
By managing risk within the same platform as your requirements, you can directly link risk control measures to the design requirements that implement them. This creates a closed-loop process that demonstrates comprehensive risk management.
Benefit: Ensures product safety is a continuous focus that woven into all project milestones, not a separate, check-box activity.
Impact: Builds a safer, more reliable product and provides clear evidence of compliance for regulators.
Step 4: Streamline Collaborative Reviews and Approvals
Formal design reviews are a critical part of the development process, but they can be slowed down by manual feedback cycles via email or comments in disjointed documents. A modern platform streamlines this with a dedicated review center.
This allows stakeholders to comment, vote, and approve items in a structured, collaborative environment. All feedback is captured in one place, creating a clear and permanent audit trail of every decision.
Benefit: Accelerates feedback loops and decision-making.
Impact: Ensures that all approvals are documented and traceable, strengthening your Design and Development File.
By providing a single platform with Live Traceability, integrated risk management, and collaborative review workflows, Jama Connect helps you build your traceability matrix as you work. This transforms it from a document you create at the end of a project into a powerful, real-time tool you use throughout the project.
Customer success stories highlight the impact. For example, Dexcom achieved a 60% improvement in systems engineering efficiency by using Jama Connect to manage its complex requirements. Similarly, Vave Health significantly reduced the time spent on traceability matrices, accelerating its development and path to FDA clearance.
The most important benefit: Jama Connect empowers engineers to focus on what they do best—designing and building life-changing medical devices—by turning the “paperwork” of traceability into an automated, value-adding process.
Q: What is a traceability matrix in medical device development? A: A traceability matrix is a document or table that demonstrates the relationships between user needs, design inputs (requirements), design outputs (specifications), risk control measures, and verification and validation activities (tests). While traditionally created in spreadsheets, modern solutions like Jama Connect provide Live Traceability, which is a dynamic, real-time view of these connections, making it far more accurate and less time-consuming to manage.
Q: How does traceability help with FDA and EUMDR compliance? A: Regulatory bodies like the FDA (under the new QMSR) and the EU (under MDR) require manufacturers to prove that their device is safe and meets all specified requirements. A complete traceability record is the primary evidence used to demonstrate this. It shows auditors that every requirement has been tested, every risk has been mitigated, and the entire development process was conducted under a state of control.
Q: Can we integrate Jama Connect with our existing engineering tools? A: Yes. Jama Connect is designed to serve as the central hub for requirements and risk management while integrating with other best-of-breed tools in your ecosystem, such as Jira, Azure DevOps, and various testing suites. This creates a connected toolchain that provides end-to-end traceability without forcing your teams to abandon the specialized tools they rely on.
Take Control of Your Traceability Process
Stop letting manual traceability processes create bottlenecks and introduce risk. By adopting an integrated approach, you can pass audits with confidence, accelerate your time-to-market, and empower your engineers to focus on innovation.
Ready to see how you can transform your product development process? Schedule a personalized demo to learn more about Jama Connect for Medical Device Development.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Tom Rish.
Jama Connect® Features in Five: Co-Development with Partners
Discover how Jama Connect empowers seamless co-development with your partners! In this Features in Five session, Mario Maldari, Director of Product and Solution Marketing at Jama Software, demonstrates how Jama Connect’s Review Center enables secure collaboration, granular access control, and iterative feedback cycles. Learn how to streamline cross-company collaboration, maintain a single source of truth, and accelerate your time to market!
VIDEO TRANSCRIPT
Mario Maldari: Hello. My name is Mario Maldari, and I’m the Director of Product and Solution Marketing at Jama Software. Today, we’ll be discussing how Jama Connect allows for co-development with partners while maintaining full control over access.
In a co-development scenario, you can share a Jama Connect project with your partner and utilize our granular permission to control access and information. You can also utilize our comprehensive Review Center and invite partners and stakeholders to participate in requirement reviews. Jama Connect is number one in enabling partner codevelopment. Thousands of engineers are already collaborating across companies today.
Some of the unique Jama Connect features that enable this collaboration are multi-tenant SaaS, no IT involvement required, centralized control of user administration and access rights, a comprehensive and collaborative reuse center, cross-company collaboration, including at mentions, subscribing, and chat streams. The Jama Connect Review Center is number one in partner codevelopment reviews.
Maldari: Some unique Jama Connect features of our Review Center are iterative review cycles with a dedicated work stream for early-stage peer reviews and final approval reviews, reviewer and approval role control, approval role delegation, related items included in reviews for context and completeness, a reviewer role at no added cost. This includes external partners, stakeholders, allowing for co-development and collaboration. In this video, we will explore how Jama Connect’s Review Center enables co-development with partners.
Arms-length relationships are moving to co-development to speed time to market. Only Jama Connect enables you to include partners in your development process and control their access. Let’s explore how this is achieved in Jama Connect today.
Any artifact or set of artifacts in Jama Connect can be sent to the Review Center. Let’s select a set of stakeholder requirements and create a new review. There are a number of options and configurations that can be selected according to your review process. Internal reviewers can be added as approvers or reviewers. External partners and stakeholders can also be invited to the review simply by adding their email address. They are provided a free license that allows them to participate in the review as codevelopers or partners.
Maldari: This allows for all review comments and sign-off from internal and partner teams to be kept in Jama Connect as a single source of truth. In this case, Jim, the project manager, will add Mario as an external stakeholder to participate in the review. Mario will receive an email with instructions and a link inviting him to participate in the review. He can simply click on the link and is able to see all of the requirements that are part of the review and comment, approve, or reject as appropriate. Here is the email that Mario has received from Jim Arlo inviting him to participate in the review. You can click on the link, open the review, and Jama Connect’s simple UI provides an easy way to go through each requirement and collaborate with the internal team. Requirements can be approved or rejected, and new versions of the review created based on updates and subsequent revisions. This can be an iterative and collaborative process between internal teams and external stakeholders.
The end result is quality requirements that are agreed to by both teams. Jama Connect’s Review Center was designed for ease of use and for collaboration with both internal and external teams, allowing for Jama Connect to be the single source of truth for co-development teams. Thank you for watching this Features in Five video on how to use Jama Connect to co-develop with your partners and suppliers. For more information, please reach out to your customer success manager or go to our website at jamasoftware.com
Delivering high-quality, compliant, and complex products on schedule and on budget is never easy. Whether your hardware and software development teams are distributed globally or nationally, achieving the necessary alignment and coordination of work activities becomes a significant challenge. Engaging your supply chain presents even higher hurdles. This article provides practical insights into fostering effective team collaboration for distributed teams to ensure that your development projects remain on track and your corporate goals are met.
Unlocking Project Success with Structured Collaboration
Why is effective collaboration critical for distributed teams?
When teams operate in silos, the risk of miscommunication, delays, and budget overruns increases exponentially. Navigating different time zones, cultural nuances, and disparate toolsets can lead to information gaps and a lack of a unified project vision. Without a structured approach to collaboration for all internal and external teams, companies struggle to maintain the alignment and coordination necessary to meet aggressive deadlines and deliver products that satisfy customer and industry requirements. This challenge directly impacts your ability to innovate and compete effectively in the market.
How does ineffective collaboration jeopardize project success and regulatory compliance?
When teams aren’t communicating and coordinating, they often miss new or changed requirements or tests. This can lead to expensive rework to address quality or safety issues or project defects during development or product recalls or customer complaints after development. For companies in regulated industries such as medical devices, automotive, or aerospace & defense, these gaps can have severe consequences including failed audits and compliance that can prevent or delay delivery to customers. A lack of a centralized, auditable trail of decisions and reviews involving all necessary stakeholders makes it nearly impossible to prove due diligence which can put the entire development process at risk. Ensuring your teams are on the same page in adhering to standards and best practices is essential for navigating complex regulatory landscapes.
What tools centralize communication and streamline critical review cycles?
To overcome these hurdles faced by distributed teams, leading organizations adopt a centralized platform for requirements, risk, and test management that facilitates structured collaboration. Individual productivity tools such as email, documents, and spreadsheets are inadequate for managing the complexity of modern product development by distributed teams because they often result in conversation fragments and version control nightmares. A dedicated platform provides a single source of truth, ensuring every stakeholder contributing to the development process is working from the most current information. This centralization is the first step toward breaking down silos and fostering genuine team collaboration among distributed teams.
How does a platform like Jama Connect® foster seamless cross-function team collaboration?
Jama Connect is designed specifically to address the challenges faced by distributed teams by combining a single source of truth with a structured environment for communication and decision-making. Its intuitive, easy-to-use Review Center functionality allows internal and external stakeholders to provide critical input and feedback directly on requirements and test cases in a clear, contextual, and traceable manner. This eliminates the ambiguity of offline comments and ensures all feedback is captured and addressed systematically. This intuitive process keeps everyone aligned, regardless of their location or time zone.
What are the tangible benefits of Jama Connect’s structured collaboration?
By implementing Jama Connect, you have the solution for completing development on time and on budget. The platform enhances team and work alignment, which reduces costly rework and accelerates development cycles. In addition, you gain greater control and visibility into the development process, allowing you to address issues that the platform automatically identifies for you and ensure compliance with all applicable safety, quality, and other regulations. This leads to faster delivery of high-quality products or systems that meet customer requirements and strengthen your company’s market position.
Take the Next Step
Ready to transform how your distributed teams collaborate and innovate? See how Jama Connect provides a centralized platform that enables your teams to work together to gather input, streamline reviews, ensure compliance, and deliver innovative products on schedule.
Engineering Governance: The Engine Behind Automotive Excellence
The automotive industry is a world of constant change. Engineering governance is the invisible engine that keeps everything humming smoothly.
Innovation to support AI-powered software-defined vehicles, electric and hybrid drivetrains, and sustainability initiatives are navigating where the automotive sector is going. But while technology makes headlines, what happens behind the scenes to manage the complexity of automotive development to stay on the right course is just as critical.
What Is Engineering Governance?
Engineering governance is a system of policies, processes, and standards that guides everything from vehicle design to production. It serves as the GPS for automotive engineering teams to ensure that they are building the right vehicles in the right way, so that every decision aligns with regulatory, safety, and quality standards and the broader goals of the company. It helps with the unification of the hardware and software siloes to not only avoid defects resulting in costly recalls and accelerate product development, but also provide an holistic operational overview of the complete engineering organization reducing risks and driving efficiency.
When designing a new hybrid, for example, engineering governance ensures that the final product adheres to emissions laws, passes stringent safety tests, and meets customer expectations. It
touches every stage of a vehicle’s lifecycle — from initial design to when it rolls off the assembly line and beyond.
AI is accelerating development of systems to enhance safety, enable convenience, and make maintenance more effective. Engineering governance will ensure that concerns about cybersecurity risks and ethical decision-making are addressed. OEMs face the significant challenge of seamlessly integrating diverse software from hundreds of suppliers. Modern premium vehicles have more than 100 million lines of software code — far exceeding the 14 million lines of code in the Boeing 787 Dreamliner. Dealing with safe-critical, non-safe, secure, open-source, and proprietary software, each with its own requirements and standards, necessitates robust engineering governance, efficient collaboration, and cutting-edge tools to ensure that the systems coexist harmoniously.
For automotive companies, failure to follow strong engineering governance risks expensive recalls, lawsuits, and fines, as well as harm to customer health and property, leading to significant negative brand impact. Here’s why getting it right matters so much:
Ensuring Compliance with Regulations: Automotive companies operate within a tightly regulated environment. Engineering governance provides a structured approach to ensure compliance with all relevant regulations across markets where vehicles are sold.
Managing Risks Proactively: Helps identify and mitigate risks early before they escalate. Without comprehensive safety and quality testing, defects might surface after vehicles are delivered to customers, rather than during development when fixes are much less costly.
Maintaining Quality Standards: A robust framework ensures that vehicles meet or exceed performance and reliability specifications without cutting corners during design, manufacturing, or testing. It enables a comprehensive view of all aspects of vehicle safety by unifying hardware and software development siloes.
Driving Innovation Responsibly: Innovation without governance can spiral into impractical or unsafe ideas. Engineering governance ensures innovation is balanced with feasibility, compliance, and cost control. Companies racing ahead with autonomous vehicle technology, for example, need engineering governance to ensure that these vehicles undergo rigorous safety tests, align with evolving regulations, and deliver innovations responsibly.
Achieving Sustainability Goals: Sustainability has become a business imperative for automakers in response to demands from governments and consumers. Engineering governance helps automakers achieve sustainability goals by embedding eco-friendly practices into every stage of development and production.
Here’s how engineering governance plays a role at every step in the development of any new vehicle or system:
Design Phase: Ensures vehicles comply with emissions standards and fuel efficiency standards in the United States, the European Union, and other regions.
Testing and Validation: Frameworks ensure rigorous testing of every component — from the engine to the suspension system and software. Engineers follow defined processes to simulate driving conditions to ensure safety and durability.
Supply Chain Oversight: Identifies system or parts suppliers whose products and processes meet quality and sustainability standards.
Post-Market Monitoring: Even after vehicles are sold, engineering governance mechanisms monitor performance through data collection to identify recurring issues and develop structured response plans to ensure quick fixes that reduce customer dissatisfaction.
For automotive executives, engineering governance is more than a technical concern; it’s a business strategy driving competitive advantage by ensuring that reliable, innovative, and compliant vehicles hit the market faster than the competition. It builds customer trust, bolsters investor confidence, and helps companies stay ahead of the constant changes in regulations.
How Jama Software Helps
Jama Software empowers automotive companies to excel in their engineering governance initiatives by providing a centralized platform called Jama Connect® that ensures traceability, compliance, and collaboration across complex development projects. By facilitating real-time alignment between teams and maintaining a clear connection between regulatory requirements, development processes, and business goals, Jama Connect helps streamline decision-making and reduce risk. This enables organizations to confidently manage innovation, comply with regulatory standards, and accelerate time to market — all while maintaining high levels of quality and accountability.
Onera Health Chooses Jama Connect to Provide Flexibility and Consistency for Sleep Diagnostic System Development Customer Story
About Onera
Onera Health develops clinical-grade remote diagnostics and monitoring solutions, making home polysomnography broadly accessible and user-friendly for anyone who needs it, wherever they are.
Customer Story Overview
Onera Health has developed a sleep diagnostic system utilizing four patch-based sensors that patients could apply at home. Initially, the Onera STS 1 product development team conducted pilot studies and relied on Microsoft Excel and Word to manage requirements and create the necessary documentation for successful Medical Device Directive (MDD) and Food and Drug Administration (FDA) submissions.
With the development of the company’s second-generation commercial product, the Onera STS 2, and its integration into Onera’s enhanced end-to-end solution, Onera Health took an active approach in recognizing and acknowledging the increased complexity of its second product. The company began seeking a more structured procedure for managing requirements, tests, and risks.
The new solution needed to provide better access, efficiency, and collaboration for teams working in different disciplines so they could accelerate development with confidence. Onera Health chose Jama Connect because it enabled faster iterations, greater consistency of requirements after changes are made, and visibility into risks and related mitigations.
Faster iterations on requirements due to less time spent in alignment, review, and audit meetings
Consistency of requirements, terminology, configurations, and documents for all teams affected by design changes
Visibility into risk identifications and mitigations for internal and regulators’ teams
“We needed a more structured approach due to the complexity involved in maintaining consistency across our entire documentation set. With our first generation, tracking the impact of a design change or updates impacting multiple disciplines was time-consuming and came with its own challenges.” – PIETER ERMERS, FOUNDER AND VP QUALITY & REGULATORY, ONERA HEALTH
Challenges
Complexity of product design, regulations, and document strategy lacking efficiency, scalability, consistency, and accessibility.
Managing requirements and tests, while maintaining document consistency, was generally challenging due to product and regulatory complexity, as well as the limitations of an on-premises document database. Additionally, accessing the database required a VPN which can slow work or interrupt progress when the connection was down.
“We chose Jama Connect because of its intuitive user experience, cloud-based availability, and flexible output that our global team needed. Jama Software Consultants were very supportive in helping us understand how to set up Jama Connect to achieve our goals.” – PIETER ERMERS, FOUNDER AND VP, QUALITY AND REGULATORY, ONERA HEALTH
One cloud-based system, accessible and user-friendly, with integrated collaboration and reviews, automated test input, and flexible reporting.
The evaluation demonstrated that Jama Connect could easily be accessed and used to manage requirements, tests, and risk based on its intuitive user interface, authoring, collaboration, reviews, and verification. Automated input of test results and flexible output in generating reports provide a tailor-fit to the company’s needs.
“When making changes in a requirement used in multiple sensors, we must maintain consistency of requirements, tests, and documents across teams and disciplines. Jama Connect’s structured approach for automatically checking that everything is covered is very beneficial for us.” – PIETER ERMERS, FOUNDER AND VP, QUALITY AND REGULATORY, ONERA HEALTH
Outcomes
With Jama Connect, the Onera team has experienced the following benefits:
Faster iteration on requirements due to less time spent in alignment, review, and audit meetings
Consistency of requirements, terminology, configurations, and documents for all teams affected by design changes
Visibility into risk identifications and mitigations for internal and regulators’ teams
In this blog, we recap a preview of our recent webinar. Click HERE to watch it in its entirety.
Making Sense of ASQMS: A New Standard for Automotive Software Quality
The Next Automotive Software Standard Is Here. Are You Ready for ASQMS?
The shift toward software-defined, new energy, and intelligent vehicles is transforming the automotive industry. As vehicles become more reliant on complex software to power advanced features, autonomy, and connectivity, the need for robust quality management has never been greater. To meet this challenge, China’s CACPQSP introduced the Automotive Software Quality Management System (ASQMS).
An overview of ASQMS, who published it, and why it matters
Key differences between ASQMS, ASPICE, and IATF, including new lifecycle requirements
Why ASQMS complements, rather than replaces, ASPICE
Practical tips for risk-based software classification and lifecycle coverage
Actionable next steps to strengthen software quality and efficiency
The Above Video Is A Preview – Click HERE To Watch The Entire Webinar
VIDEO TRANSCRIPT PREVIEW
Ronald Melster: Thank you very much for the warm introduction and thank you very much also for inviting me to today’s webinar. I am excited to be here with all of you and to share with you the information about this new standard ASQMS. So let’s get started and explore what the standard means for the automotive world and how we can best adapt to it. For those of you who don’t know me yet, my name is Ronald Melster. In the automotive world, I’m simply known as Ron. As one of Europe’s most experienced Automotive SPICE principal assessors, I have spent nearly three decades helping organizations transform their development processes. Since 2005, I’ve been guiding teams not just to achieve higher capability levels, but to truly understand the why behind effective processes. My journey began in the 1990s when I studied computer science in Berlin and Edinburgh, but I quickly discovered my passion for software engineering and processes. What started as a love for coding evolved into a mission to help teams balance structure with pragmatism.
Over the years, I have had the privilege of working with industry leaders like Bosch, Audi, Porsche, and Here Technologies. One of my biggest achievements was leading a Bosch development division with 7,000 engineers worldwide to capability level 3, proving that even larger teams can embrace systematic improvements. But here’s what I’ve learned. Assessments are not just about ratings. They’re about empowering people, building confidence, and creating sustainable change. Whether it’s functional safety according to ISO 26262, cybersecurity, or process improvement initiatives, I’m here as your mentor, coach, and sparring partner. Maybe you have heard the rumors about this new China standard and you want to learn more about it. You have come to the right place. Let’s start with the name of ASQMS, Automotive Software Quality Management System. That’s the full name of the standard, and yes, it’s a Chinese standard.
We will take that apart piece by piece in this webinar. So the first question is which body exactly published this ASQMS standard? And the answer is the Chinese Association of Consumer Products Quality and Safety Promotion, short CACPQSP. Say this three times. This body is dedicated to consumer rights and their safety and regulates consumer products, including cars. To promote this, they created the ASQMS standard and demand that each OEM selling cars in China needs to be certified according to the standard. So naturally, it applies to Chinese OEMs selling in China, and it also applies to European OEMs wanting to sell cars in China as well. And there’s more. The OEMs are required to request the certificate from their suppliers as well, so it also applies to any supplier tier two or tier one if they want to be part of the supply chain for cars sold in China.
Let’s have a look at why they created the standard and why we need another standard if we have Automotive SPICE or ASPICE. The reason for that is the dependency on software in the car. The complexity is growing rapidly. The number of technical and organizational interfaces gets bigger every day, and the cars increasingly rely on data coming from the outside. Let me share an observation with companies trying to reach capability level 2, according to Automotive SPICE. At the beginning of the project, the capability level is at a stable level 0. Then it takes one, or two, or even three years to get to level 1 and then to level 2. Then the project delivers the result and is finished. And the next project start again at level 0. I call this cycle the chainsaw or zigzag, up and down and up and down. It’s a huge waste of time and effort, and might have led to the ASPICE frustration, which we observed in networks like LinkedIn.
Melster: Why is that? Because the knowledge is not captured after the project in the company, nor is it standardized or rolled out. Only few companies have managed to establish a stable level 3 with a standard process according to ASPICE. Why can a project not start in a systematic way, aka level 2 or level 3, from the start of the project? This will also reduce the technical debt, which is built up every time a project starts from level 0. There are some of the reasons why this new standard was developed. We need a strong focus on software development. We need to include the software outside the vehicle, and we need to focus on the organization to provide standard process which is applied in each and every project in a similar way. And I might add that we need to take care of the software long after the initial development phase. In a world with rising cybersecurity issues, the software must be maintained and updated if new threats become known. Therefore, ASQMS includes the entire life cycle, including the termination of the software with a systematic deletion of all personal data.
Let’s talk about what’s inside the standard ASQMS and how it’s structured. The standard contains three kinds of requirements, which must be implemented by a company which wants to be certified according to ASQMS. The first one are basic practices, not base practices, but basic practices. They’re mandatory for all automotive development. The second kind of practices are advanced practices. They must be implemented by products which are safety or cybersecurity relevant. And the third type of requirements are recommended practices. They should be implemented by all software projects. The ASQMS standard follows a risk-based approach, which means that not all requirements, which are defined by the standard need to be implemented in each development program. For that, a classification is introduced, the two classes or types of software.
Type II is a software that carries a risk related to safety or cybersecurity, and type I is the rest of the software, which is not related to safety or cybersecurity. For type II software, the cybersecurity or safety-related, the basic practices are mandatory, and the advanced practices are mandatory. The recommended practices are recommended. For type I software, which are not as critical, only the basic practices are mandatory, and advanced and recommended practices are optional. ASQMS clusters the processes into three groups: operational processes, supporting processes, and system management processes. The operational processes include project management and the entire V-model with requirements engineering, architectural design, detailed design and implementation, unit verification, integration, and verification testing.
Apart from these well-known engineering processes, the following processes are defined as part of the operational processes: supplier management, software release, software deployment, software maintenance, user information management, and software termination. So there’s some overlap and some new processes. The supporting processes include some which we already know from Automotive SPICE like configuration management, problem resolution management, change request management, and of course, quality assurance. They even have the same process names. The basic practices may differ in some aspects. And some new supporting processes are introduced like documentation management, equipment and facilities, knowledge management, revenue management, and externally supplied products and services, which includes the management of free and open-source software.
Melster: With the system management processes, something completely new is introduced. They’re not to be confused with the system development processes, which we know from ASPICE. System here refers to the quality management system in the name of ASQMS. So it’s similar to ISO 9001, or ITF 16949, or an information security management system, which gets certified by TSACS. These processes include the scope and the context of the organization, the quality management system fundamentals like quality policies and roles, personnel management, performance evaluation, and the continuous improvement process. In this next section, I will highlight some of the key changes when we compare Automotive SPICE with ASQMS. The first one is the software, which is in the scope of the standard ASQMS. The requirements are not only mandatory for in-vehicle software, which many of us have known for a long time, but also for software outside the vehicle is in scope.
This includes any software in the cloud providing data to the vehicle or to an entire fleet. It furthermore includes any system along the roads, so-called roadside systems. Again, exchanging information with the car or even controlling the behavior of the vehicle. And it applies to the software tool chains which are used for software development and maintenance. The next important change is the lifecycle. Automotive SPICE development projects typically stop with the release of the finished software, whatever this means. The maintenance phase is usually left out or ignored, and really no one thinks about the termination of the software in an ASPICE project. This will change with ASQMS. The entire lifecycle of the software must be covered. This only starts with the initial development phase and must be continued with the ongoing maintenance of the software until the termination of the software. You might want to know, what is the termination more than switching off the software? Well, many software instances store data, oftentimes personal data, and this information must be securely deleted as part of the termination.
Many companies claim that they are ASPICE level 2 certified. However, this is not true. There is no such certification. What they have reached in most cases is a level 2 in one project at a certain time. So this does not apply to any other project in the same company without performing additional assessments, nor is the claim true in the future or after the assessment for the same project. So here’s the last key change I will talk about. ASPICE assessments are statements about projects at a certain point in time. This statement cannot be carried over to any other project in the company, nor is it valid in the future. ASQMS, on the other hand, focuses on the organization. This means that the organization must establish processes to fulfill the requirements and maintain them in each and every development project. This also includes internal auditing activities to make sure that all projects follow the defined rules and methods. And as I’ve mentioned earlier, it also includes processes to provide competence staff to the project. Only then will the company get the ASQMS certificate, which is published by an external auditor.
So what have we learned today about how ASPICE and ASQMS can work together? First, ASPICE integration. ASQMS will not replace Automotive SPICE. Instead, ASPICE can be used to show the conformance with the overall standard processes. And if you are already using ASPICE at the project level, these methods can be scaled to the entire organization using the approach of ASQMS. Second, both standards have shared goals. They’re built on the same fundamental principles, traceability, clear structure, and well-defined roles. Whether you’re working on a senior development project or managing quality across multiple teams, these core elements remain the same. And finally, ASQMS is extending the scope. Here’s where ASQMS goes beyond traditional ASPICE scopes. It adds organizational elements like leadership development, culture building, and personnel focus. The reality, ASPICE and ASQMS work as a partner, not competitors. Automotive SPICE gives you project-level excellence while ASQMS builds the organizational capability to sustain that excellence across all your software activities. Together, they create a comprehensive quality approach that works at every level.
