Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from MedTech Dive, titled “FDA Class I Recalls Hit 15-year High in 2022” – originally authored by Nick Paul Taylor and published on March 3, 2023.
FDA Class I Recalls Hit 15-year High in 2022
Dive Brief:
The number of Class I medical device recalls by the U.S. Food and Drug Administration hit a 15-year high in 2022, according to a report by Sedgwick.
In 2022, the FDA oversaw 70 Class I recalls, its highest risk classification, compared to an average of 47 over the previous five years. Eighteen of the Class I recalls happened in the fourth quarter.
Mislabeling was the most common reason for recalls in three of the past five quarters.
Last year, companies including Abbott, Baxter, GE HealthCare, Medtronic and Philips were the subject of Class I recalls, a category that the FDA reserves for problems with the potential to cause serious injury or death. The activity added up to a record year for Class I recalls.
Sedgwick reported the 15-year high for Class I recalls after tallying up the data for the fourth quarter. Over the final three months of the year, the total number of recalls of any type rose 8.1% sequentially, and the number of recalled units increased by around 10 million to 61.98 million.
Mislabeling was again the most common cause of recalls in the fourth quarter, as it has been for three of the past five quarters, followed by quality. There was a decline in the number of recalls related to software, the most common cause of recalls in the third quarter. Having been responsible for 46 events over that prior period, software accounted for 15 recalls in the final three months of the year.
Based on data for January, the increase in recalls between the third and fourth quarter may continue in 2023, the report said. Sedgwick counted 135 recalls in January, compared to a monthly average of 80 in the fourth quarter. The number of recalled units is also tracking above the rate seen in the fourth quarter.
Sedgwick identified the FDA’s use of Section 518 authority, which allows it to order manufacturers to notify patients and providers of risks, as one of the most significant developments in medical device recalls. The FDA used the power one year ago to order Philips to tell patients about its respiratory device recall because the company’s efforts to that point had been “inadequate,” the agency said.
Digital Transformation of Verification Process for Faster Aircraft Certification
The certification of new aircraft programs is expensive. Whether it is an advanced air mobility system, a (hybrid-) electric aircraft or a military aircraft with new weapon systems, new and innovative aircraft programs are very complex. The application of new materials, additive-manufactured structures, electrical propulsion systems and an increase in onboard software requires extensive virtual and physical testing to verify whether the aircraft is safe, reliable and cost-effective to fly.
Managing verification from the start of the program, as soon as the requirements have been defined and validated, is a good practice. As the verification job is huge, especially for start-up programs, a digital verification management platform can significantly reduce the risk and related over-budget costs of aircraft certification.
Challenge – Aircraft Complexity
There’s a reason why airplanes are the safest mode of transportation: certification. For aerospace manufacturers, aircraft certification is everything. No certificate means no product to market.
In addition to already strict EASA, FAA, and other regulations, companies face additional demands for advancements, including – but not limited to – sustainability targets and the ambition to fly autonomously, which require more integrated systems driven by software and electronics.
New technologies like this are exponentially complex. They impact all aspects of product development, including design, validation, and testing. Instead of a few components and hundreds of interfaces, there are now thousands of components with tens of thousands of interfaces. More and more functions are implemented through software.
Therefore, it’s no surprise that today, aircraft certification is more costly than design. This is a huge challenge. Many companies have great ambitions with new aircraft configurations. It is now technologically and financially feasible to build and fly prototypes and validate concepts. The big financial challenge and risks that a company faces are the costs of aircraft certification and industrialization. Indeed, Porsche Consulting estimated in 2018 that the series development and type certification of an eVTOL urban air mobility aircraft would cost between $500 million and $1 billion1, and Archer Aviation CEO Adam Goldstein says, “the price-tag for one aircraft design to reach certification could be up to $1 billion”.2
This represents a serious risk to many companies. As an aeronautical engineer, I cannot be more delighted when I see all the initiatives taken to exploit the possibilities of new propulsion systems into radical new aircraft configurations. In that sense, the last 5 to 10 years are comparable to the 1950s, when a lot of new aircraft configurations were explored. However, I’m worried that many companies with exciting new ideas will financially fail before getting aircraft certification.
One should not forget that many of these companies have to build the elements for proof of compliance from a blank sheet. They cannot count on data from previous programs to alleviate the verification process by comparison. This puts them at a competitive disadvantage against legacy companies, which might be less innovative but have an abundance of verification data at hand.
Because of the above, new organizations tend to postpone addressing the verification and certification aspects.
Opportunity – Certify During Development
Digitalization environments offer a lot of capabilities to pre-empt the aircraft certification aspects and associated risks.
Process-wise, companies should consider including the verification and certification process within the aircraft design, development production and quality process from the start of the program.
Different digital platform pillars are key in this.
It Starts with the Digital Twin
Throughout the development of aircraft, digital twin capabilities make it possible to design, engineer and optimize the aircraft and its systems. They provide engineering insight into how the aircraft is built and how it performs behaviorally. The use of a digital twin model enables manufacturers to become exponentially more accurate in all aircraft domains, covering all “engineering physics,” which define how well it operates.
Given good management and validation of the modeling assumptions, these digital twin models can be further exploited to verify the behavior of electro-mechanical systems, coupled to the software-based control functions. Indeed, once one gets confidence in how well the models represent reality, these models can be used to perform virtual testing and alleviate the burden and costs of physical testing.
The ability to author these virtual test models is dependent on having the necessary skill tools for generating the engineering analysis data.
An additional benefit of digital twin models is that they not only help with accelerating the verification based on virtual testing, but they also have an under-recognized value in preparing and de-risking the physical tests, which will be needed anyway.
Indeed, as long as innovation continues to occur in this industry, it will be necessary for companies to prove the accuracy of their modeling assumptions, methods, and processes to aircraft certification authorities and organizations.
Digital twin technology is essential when programs want to reduce the risks related to aircraft certification. However, there is a closed-loop process needed between virtual and physical testing in order to make this a viable strategy.
The amount of engineering analysis data a digital twin generates is enormous and requires a digital data and process management backbone to control it, keep it in configuration, manage the processes and make sure all data is traceable.
This backbone is also very important for the next programs. Indeed, stored data does not only serve current programs, but also can be reused in future programs to avoid verifying aspects multiple times on different programs. This drastically reduces verification costs of future programs, whether by simply re-using data or proving digital twin modeling assumptions were right and avoids physical verification on these aspects on the next program.
Digital Thread
The generation of engineering data using digital twin technology along with excellent data management is a start, but to be truly effective, the digital platform needs to keep all data generated and managed in the context of the aircraft program, as it assures the digital continuity of engineering data with the engineering decisions taken. As part of a model-based systems engineering (MBSE) approach, a verification management digital thread can provide a traceable link between the requirements and the artifacts that lead to the proof of compliance of that requirement, including all its intermediate data like the eBOM, test-BOM, etc.
Solution – Verification Management
A verification management digital thread should be a vital part of the digitalization strategy of all aerospace and/or defense companies. It can help make certification an integral part of the overall product development process and enable companies to have a robust certification execution plan and incorporates all the needed certification activities within the overall program plan.
It is vital that companies embrace not only a verification management digital thread, but also a full digitalization strategy. Digitalization enables aerospace manufacturers and their supply chain partners to make better-informed decisions based on extensive data and analysis as well as full traceability. It is the only way to turn the increased level of complexity and integration inherent in new programs into a competitive advantage.
The aerospace and defense industry is going through a time of immense innovation, and I’m excited to see what the future holds as A&D companies and teams of all sizes adopt digitalization to deliver on the promise of this innovation.
References
1. The Future of Vertical Mobility, Sizing the market for passenger, inspection, and goods services until 2035, A Porsche Consulting study, 2018
2. Can UAM developers turn their electric dreams into a reality? Pilar Wolfsteller, 2022
About the Author
Thierry Olbrechts is the Director of Simcenter Aerospace Industries Solutions, Siemens Digital Industries Software. In 1996, he joined Siemens Digital Industries Software. Since 2000, Thierry has been responsible for Siemens simulation and test business development and go-to-market strategies for the aviation, space and defense industry segments.
In this blog, we recap the “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System” webinar.
In this webinar, “Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System”, learn about the implementation of the Threat and Risk Analysis (TARA), the centerpiece of the new Automotive Cybersecurity standard ISO 21434.
Many companies currently use spreadsheets to develop TARAs, which can be challenging when managing large sets of requirements across distributed teams and car line variants. In this webinar, we’ll examine why a requirement management system (RMS) is well-suited to manage the TARA work product and can make a significant impact on managing this data across teams, supporting compliance audits, and assessments.
Attendees will gain insights into TARA’s complexities and how the right tooling solution can make a difference in managing this data across teams, supporting compliance audits and assessments.
Key Takeaways:
The Threat and Risk Analysis or TARA is the centerpiece of the ISO 21434 Automotive Cybersecurity standard
Overview of TARA
ISO 21434 compliance requirements when implementing TARAs
Why an RMS is well-suited to manage TARAs
Below is an abbreviated transcript and a recording of our webinar.
Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System
Kevin Dibble: Thanks, Juliet. Okay. I’m going to just go through the agenda and then get right into 21434. I’ll start with a high-level introduction and then get into the focus of our topic today, which is the threat and risk analysis, which is a centerpiece of 21434, also known as the TARA. And then make an argument for the management of a TARA using an RMS or a requirement management tool. And then Steve will take over and talk about what that would look like in Jama software and summarize with some key points of managing TARAs in Jama versus some traditional methods. And then we’ll have time for some questions.
So with that, again, this is going to be a very high-level overview of 21434. I have a feeling that some of you have worked in cybersecurity for some time, others are just brand new to the term. And so, I want to touch on this as a basis for the rest of the discussion.
And so, first, what is 21434? It is the automotive industry standard for developing cyber secure systems. After several years of review, it was approved in August of 2021 as the method for developing cyber secure systems. In terms of the standard itself, it’s structured and uses a lot of the same terminology as the functional safety standard called ISO 26262. So if you’re familiar with functional safety, then this standard will make a lot of sense the way that it’s organized. Some of the terms such as an item definition, a concept phase, a cybersecurity goal, even TARA parallels functional safety terms like functional safety concept, functional safety goals, or the HARA, Hazard and Risk Analysis. And so, that’s just a reference point as you’re learning about this new standard. Now as far as its scope, it covers or it applies to passenger vehicles and cargo vehicles.
So just a little bit different than ISO 262 there, passengers would include buses, commercial or non-commercial. I think even tripods and some of those other types of motorcycle hybrid type of devices are in or vehicles are in scope as well. It applies to series production and it uses a lifecycle that starts at the request for a quotation for an item. And I’ll define that in a little bit and goes all the way through to the end of cybersecurity support. So like functional safety, we’re not talking about supporting the risks and the hazards associated in this case with threats from attackers leading up to SOP, but it extends far past that. In fact, in 21434, instead of using the term SOP or start of production, which is a critical milestone in any automotive product development program, they call that milestone the release to post-development.
Dibble: And I want to camp on that for just a second because it raises a really important point and it’s very relevant to what we’re going to talk about regarding the TARA. Release to post-development. So the automotive industry is under a lot of change and OEMs want to be or are becoming mobility providers and services will be sold after the car is released. And some of those services weren’t even imagined at the time the car was sold. That’s so different than where the automotive industry was even five years ago. And this standard recognizes that and embraces it along with another important concept, which is that the world of cybersecurity and the landscape for threats and the technologies and the tools that are used to attack vehicles is constantly changing. And so, at the release to production, what is assumed to be protected in terms of say a set of cryptographic keys or a communication bus might be more vulnerable in five years than it was when the car was released because of new techniques, new methods, new tricks, new hacks, and other things that have been discovered.
And so, that’s an important concept because it feeds to our idea that we’re going to get into about the TARA as a living document, as a living asset that begins all the way at the concept phase at the beginning of the high-level architectures of the item or the system in the car. And extends all the way until the end of life for cybersecurity support, which is 10, 15 years down the road. Now, the 21434 has both requirements for developing cyber secure systems, is kind of what I’m showing you on the right, but it also has process requirements. And to that end, there is an audit of the process and an assessment of the results of your project according to 21434. That assessment piece is important for our discussion because when we think about the TARA and the pieces of it or the items of the TARA, then we have to think in terms of what are the evidences we need to leave behind and produce in order to pass an assessment, very important consideration.
Dibble: And so, we have audits for the processes and then assessments for the end result. So that’s very brief overview of 21434. I want to make sure I leave you with the… If you remember anything about 21434 besides the TARA, you’ll hopefully remember this, is to manage unreasonable risk of damage to road users due to a malicious attack to a vehicle or a vehicle data, confidentiality, integrity and availability. Let me unpack that for just a second. Unreasonable risk, this is when you get into a car, when you operate a vehicle, you assume some risk. But that risk doesn’t include driving down the highway at 70 miles an hour, turning right and the car going left or the headlights going off while you’re on the highway at night. It applies to road users. That’s the people that use the road, the driver, the passengers, and the people surrounding it.
All of that is our scope for how we’re going to define threats according to 262 and then mitigate them against malicious attack due to… That’s the cyber aspect of this. And then what’s being attacked and what are we protecting? We’re protecting vehicle systems, functions, data, et cetera. We call them assets according to their properties, confidentiality, integrity and availability. There could be more properties, that’s the CIA that we’re protecting. Why is cyber such a hot topic? Well, I would say there’s several reasons, but here’s two of the big ones. On the left of my slide, the advent of the connected car coupled with the automated driving functions. I’m not going to read through all the stats here, but the connected car is here. It’s 2 billion in terms of the market in 2021 to grow to $5.3 billion in 2026. And the connected car is accessible via the internet, accessible via Bluetooth and other network interfaces, which all result in attack services. It also has a lot more software.
This is part two of a two-part series on software validation and computer software assurance in the medical device industry.
Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part 2
In our previous blog post, we reviewed the top things to know about software validation and computer software assurance in the medical device industry. In this installment, we’ll take a closer look at computer software validation and provide tips and tools to manage your software in a compliant and efficient manner.
Main points
The FDA Draft Guidance on Computer Software Assurance
In September, 2022, the FDA released its draft guidance “Computer Software Assurance for Production and Quality System Software.” While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance on Software Validation, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). In this guidance the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”
There are many types of software used and developed by medical device companies, including those listed below. The scope of the 2022 draft guidance is on software used in production and quality systems software, as highlighted below.
Software in a Medical Device (SiMD) – Software used as a component, part, or accessory of a medical device;
Software as a Medical Device (SaMD) – Software that is itself a medical device (e.g., blood establishment software);
Software used in the production of a device (e.g., programmable logic controllers in manufacturing equipment);
Software in computers and automated data processing systems used as part of medical device production (e.g., software intended for automating production processes, inspection, testing, or the collection and processing of production data);
Software used in implementation of the device manufacturer’s quality system (e.g., software that records and maintains the device history record);
Software in the form of websites for electronic Instructions for Use (eIFUs) and other information (labeling) for the user.
Understanding Your Software’s Intended Use and Risk-Based Approach
Defining the software’s intended use is an important aspect of managing your organization’s computer software assurance activities.
This then allows you to analyze and document the impact to safety risk if the software failed to perform to meet its intended use. One aspect that I appreciate the FDA adopting is the concept of ‘high process risk,’ when the failure of the software to perform as intended may result in a quality problem that foreseeably compromises safety and an increased medical device risk. The guidance has a number of examples to illustrate examples of high process risk and not high process risk. Previously, risk that purely a high risk to compliance only (i.e., no process risk) was essentially treated the same as risk that could compromise safety.
Commensurate with the level of process risk, guidance, and examples are presented to outline expected computer assurance activities, including various levels of testing, and level of documentation. Computer assurance activities for software that poses a high level of process risk include documentation of the intended use, risk determination, detailed test protocol, detailed report of the testing performed, pass/fail results for each test case, any issues found and their disposition, among others.
In contrast, guidance is provided that computer software assurance activities that pose no level of process risk can consist of lower level of testing, such as unscripted ad-hoc or error guessing testing. Prior to this guidance, the expectation was fully scripted protocols and documented results for each test case, which felt burdensome. For example, having to script out protocol steps to include user log-in steps for an electronic QMS module that facilitated the nonconformance process, which did not have a high level of process risk. The usage of the concept of high process risk and acknowledging that unscripted testing can be appropriate in times of low risk, will certainly help lessen the burden of compliance, without compromising safety.
Managing Your Software Efficiently
For those that think analytically like me, once can easily see the value of a Trace Matrix to keep my organization’s software organized and ensure the intended use, risk assessment, planned computer software assurance activities, and outcomes documented.
Similar to how it efficiently traces your medical device design inputs to outputs and links to your risk management, Jama Connect® is a great tool to also trace and manage all your software and software validation and computer software assurance activities. This includes documentation of the intended use, risk determination, and test protocols and reports performed. With its new validated cloud offering, SOC2 certification, and available Jama Connect Validation Kit, Jama Software also provides the tools and evidence you need to meet your organization’s computer software assurance activities.
Developing a risk-based process for software management, including software validation and computer software assurance, is key to staying compliant. Staying organized and using a tool like Jama Connect helps you do so efficiently.
Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from MedTech Dive, titled “Medtech industry relieved as Europe’s MDR extension nears final approval” – originally authored by Susan Kelly and published on March 6, 2023.
Medtech Industry Relieved as Europe’s MDR Extension Nears Final Approval
The Council of the EU is expected to vote Tuesday on an extension of deadlines for complying with Europe’s Medical Device Regulation (MDR), in a move to keep critical treatments on the market during the transition period.
The revised timeline would give notified bodies that certify devices in the European Union longer to prepare for the new regulatory framework.
Companies that operate in the European market were expected to have devices recertified by May 2024 under the regulation, but with the deadline approaching, notified bodies faced a backlog, prompting the European Commission to propose extending the time frame.
“Industry is relieved that these amendments have been introduced – they are the culmination of many warning signs about a potential shortage of medical devices in the EU,” Brussels-based life sciences lawyer Josefine Sommer, a partner at Sidley Austin, wrote in an email.
The extension would stagger deadlines until 2027 or 2028, based on device risk classification, allowing manufacturers and notified bodies more time to complete conformity assessments. Products placed on the market under the predecessor Medical Devices Directive (MDD) could remain, under certain conditions.
“Once the amendments have been adopted, it will be interesting to see how the conditions for benefiting from the additional transitional periods are to be interpreted and implemented in practice,” Sommer said.
The upcoming European Council vote follows the European Parliament’s approval last month of the new timetable. EU procedure calls for both branches of the legislature to approve the plan.
“This will be the final step in the process,” an EU official said in an email.
Member state health ministers in the EU’s Employment, Social Policy, Health and Consumer Affairs Council backed the plan in December, after European medical societies called for urgent action to address device supply shortages reported by physicians.
“The Health Council supported the European Commission’s proposal to delay the transitional deadlines to avoid causing harm to EU health systems and, most critically, patient care,” London-based attorney Lincoln Tsang, partner and head of Ropes & Gray’s European life sciences practice, wrote in an email.
The MDR was adopted in 2017 following the recalls of breast implants and metal hip replacements due to safety problems. The regulation tightens controls for the safety and performance of medical devices and includes stricter monitoring and certification procedures to ensure compliance and traceability. The new rules also are intended to reflect technological and scientific advancements in the sector.
With the extended deadlines, higher-risk devices such as implants must transition to the new requirements by December 2027, and medium- to lower-risk devices such as syringes or reusable surgical instruments have until December 2028.
But Erik Vollebregt, a founding partner of Axon Lawyers in Amsterdam, said the timeline still requires manufacturers to be MDR-ready, “with an MDR application in the door at a notified body” no later than May 26, 2024.
“The current state of the market is that everybody is still figuring out what the proposal will mean for them specifically, both industry and notified bodies. Some manufacturers have seen 2027 and 2028 as dates and do not understand that these are dates for notified bodies and not for manufacturers,” Vollebregt said in an email.
Reuters reported in December that medical device manufacturers were dropping products from their European portfolios because of the cost of complying with the new regulations.
Although six new notified bodies received MDR designation in the second half of last year, it created a pool of 36 organizations to process around 23,000 certificates of current devices on the market, prompting EU Health Commissioner Stella Kyriakides to propose delaying enforcement of the MDR.
Functional Safety (FuSA) Explained: The Vital Role of Standards and Compliance in Ensuring Critical Systems’ Safety
Have you heard of FuSA? It stands for Functional Safety, and it is a vital part of any system that requires safety assurance. FuSA was designed to reduce the risk of physical injury or damage due to malfunctioning equipment. This guide will provide an overview of the subject, including the standards, compliance requirements, and the different types of systems where FuSA is used.
What Is Functional Safety?
At its core, Functional Safety (FuSa) is a set of measures taken to ensure that a system meets certain safety requirements. In other words, it’s a way to make sure that any system can operate safely without causing physical injury or damage. This includes both hardware and software components within the system.
The goal behind FuSa is to reduce the risk associated with a product’s failure as much as possible through the use of safety systems that are designed to detect any potential hazards and then take corrective action if necessary. To do this, developers must consider both hardware-based solutions such as monitoring devices or sensors, as well as software-based solutions such as algorithms or machine learning models that can detect potential faults before they occur. Once all potential risks have been identified and addressed, designers must then create a comprehensive test plan to validate all safety system components before the product is released into production.
FuSa Standards and Compliance Requirements
Several international standards have been established to help guide organizations in their implementation of FuSa. These standards include ISO 26262 for the automotive industry and IEC 61508 for industrial manufacturing and consumer electronics sector. Both these standards establish minimum requirements for safety-critical functions within a system. Additionally, each standard specifies certain testing procedures that must be followed in order to demonstrate compliance with the standard.
Typical Applications of FuSa
FuSa is commonly used in aerospace and defense applications as well as road vehicles, industrial machinery, medical devices, consumer products, and more. It can also be applied in critical systems such as those involving control functions or power generation/distribution systems. In all cases, the goal is to reduce the risk of unacceptable physical harm or damage due to malfunctioning systems or components.
When creating a safety system using FuSa principles, engineers typically use several tools such as FMEA (Failure Modes Effects Analysis), FMEDA (Failure Modes Effects & Diagnostic Analysis), FHA (Functional Hazard Analysis) etc., which are all based on the IEC EN 62304 standard for software development processes in medical devices; Road Vehicles Functional Safety Standard (ISO 26262); IEC 61508 for industrial automation; etc., all depending on what type of product/system one has in mind when developing a safety critical E/E/PS (Electronic / Electrical / Power Supply). All these rules vary depending on what type of product is being developed but usually involve assessing potential risks from different scenarios and establishing suitable safeguards against them so that they meet certain Safety Integrity Level requirements laid out by ISO/IEC 61508 standard.
Functional Safety is an important consideration for any organization dealing with safety-critical systems or components involving significant risks from potential malfunctioning equipment or software failure leading to unacceptable physical harm or damage caused by the equipment itself. Engineers must use proper tools like FMEA & FMEDA during development process while ensuring adherence to standards such as ISO 26262 & IEC 61508 while developing their products meeting necessary Safety Integrity Level requirements laid out by these standards. As long as organizations are aware of these requirements and take steps towards implementing them properly into their products & services they should be able to develop reliable & safe products meeting customer expectations!
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Steve Rush.
In this blog, we recap the “Launch Your Aerospace & Defense Product Development Processes with Jama Connect®” webinar.
In this webinar, we discuss exciting new features in our updated Jama Connect® for Aerospace & Defense framework. These updates include refreshed solutions for cybersecurity, the DoD Range Safety Requirements Library, and other libraries of standards.
Also, Cary Bryczek, Solutions Director for Aerospace & Defense at Jama Software®, shares best practices in the Jama Connect platform and demonstrates significant new features that can help you further enhance your aerospace and defense product development processes, including:
ARP 4761A – Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment
DO-326A – Airworthiness Security Process Specification
US CFR Parts 21-57 Pre-imported Libraries and Usage
Defense MBSE and Digital Engineering Guidance
NASA and Air Force Range Safety Requirements
European Cooperate with Space Standards (ECSS) Pre-Imported Libraries
Below is an abbreviated transcript and a recording of our webinar.
Launch Your Aerospace & Defense Product Development Processes with Jama Connect®
Cary Bryczek: Let’s get started. So the Airborne Systems Solution. So when we say solution, it’s really a complete set of frameworks, example projects and the procedural documentation that goes along with that. It’s really intended to accelerate your implementation of Jama Connect, especially those that are developing Airborne Systems and the Airborne Systems components that are going to live on these aircraft. When you utilize these frameworks, you can either have zero set up time, so we’re developed the solution to align with the standards and you can also tailor it. So your consultant who does team with you could help you tailor it to meet your very specific business needs as well. So it’s really designed for any organization, whether you’re a startup in the Airborne Systems world or whether you’re a longtime developer of aircraft.
The Airborne Systems Solution is really designed to help you ease the path to regulatory compliance, to help the engineers produce the evidence and collect that evidence in coordination with the regulatory requirements and the industry standards that are used that are requiring the acceptable means of compliance. Today’s. In today’s world, there is a lot of new engineers that are being employed in Airborne Systems development. And really this particular template is helpful to them because it really gets them to understand “How am supposed to do development?” We all know that Airborne Systems development has the most onerous and rigorous standards of any industry. And teaching our new engineers is very time-consuming. So having this template with all of the guidance built into it and the procedure guide really helps our new engineers to get started.
So there’s three components to the Airborne Systems Solution that what we call the data set, a procedure guide, and the success program. The data set essentially is what you get when you install Jama and it has the templates, it has a ready to use configuration that matches those regulations. It has all of the item types, all of the reports, all of the best practices built right in. And then the procedure guides and the documentation of the reports essentially show you how the Airborne Systems template is meeting the industry standards. So how does it meet ARP4754, how do you use the solution to meet DO-178. That’s sort of a thing.
Bryczek: And then we also pair our solution with specific consulting. So our consultants already are very familiar with the regulations with working with our customers that have been delivering and developing Airborne Systems already, as well as systems engineering best practices. Some of our customers have interesting supply chain needs. And so they might want to use an additional tool that we package called data exchange. That’s just an add-on to the solution.
So when we look at the framework itself, there are a lot of industry standards that we support. These industry standards are the acceptable means of compliance that the FAA and EASA recognize in order to meet type certifications. So we have those processes that come right out of those standards built right in to the framework. So that framework consists of specially configured item types, pick lists and views of that information. Our relationship rules are aligned to the types of trace matrices these particular standards are calling for. We have workflows and guidance for how you conduct reviews of information as well. We have the libraries of standards, so if you need to comply with the different CFR parts, we actually have those pre imported. This is something new that we’ve added and we’ll talk about that a little bit more. The framework includes these document export templates as well as risk templates and analysis templates and more.
Now this is a company with a procedure guide. So along with not only just the template itself in Jama, we give you the procedure guide. You can take this guide and tailor it to meet your specific needs as well. This procedures guide is updated. So as a subscriber to the Airborne Systems Solution, any updates we make or new releases like what we have right now is included with your subscription. It just makes it easy for everyone to kind of understand “How do I use Jama if I need to meet these industry standards?”
Bryczek: Also with this particular release is the configuration and update guide. So this is new this time around. This particular guide gives a very detailed description of the entire dataset. It includes all of the types that we’ve defined, all of the pick lists that are defined, all of the relationship rules, all of the workflows. So if you need to update from your existing Airborne Systems Solution and take in aspects of the new release, it makes it really easy for you guys to update as well. This might be something as well… So if you tailor from your existing Jama solution and you want to keep track of that, something like this might be a really great way for you to document your own implementation of Jama itself.
So exciting. This is one of the new things. So we have for cybersecurity, DO-326A is an acceptable means of compliance for doing security analyses. There are a significant number of new item types that have been added to the solution that comprise our cybersecurity solution as well as how do you really do the airworthiness security analysis. Essentially there are seven steps to do this particular type of analysis. This really starts with developing your PSecAC. And for those of you who are maybe new to Airborne Systems development or are not familiar with DO-326 or cybersecurity, it is a process that’s sort of done in tandem with both the system development and safety. But this is different in that this is analyzing the intentional unauthorized electronic interaction. So it’s really designed to find ways that hackers or bad actors might be accessing parts of the Airborne Systems that you don’t want them to.
Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I
Intro
This is Part 1 of a 2-part series on software validation and computer software assurance in the medical device industry.
While it is clear that software validation is required by regulation in the US and elsewhere (e.g., the EU (European Union)), as regulated by the MDR and IVDR), how to execute continues to cause challenges, both for established medical device companies, and those just entering the medical device industry.
Between the different types of software, variations in terminology, type, and source of software (developed in-house, or purchased OTS, customized OTS (COTS), SOUP, etc.) advances in software technology, and evolving guidance of the FDA (Food and Drug Administration) and other regulatory bodies, it’s no wonder that implementation of software validation practices and procedures causes confusion.
This blog outlines the top things to know about software validation and computer software assurance as you implement practices and procedures for your organization in a way that is compliant and brings value.
Are you building or updating your software validation practices and procedures? If so, read on!
Top Things to Know About Software Validation and Computer Software Assurance
#1. Yes, there are different terms, methods, and definitions for software validation.
For the purposes of this blog, we’ll use the FDA’s definition of software validation, from their 2002 guidance. The FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”
At a high level, this makes sense. The confusion starts when folks try to define how that confirmation is performed and documented. How do I determine and document the requirements? How detailed do I need to go to my user needs and intended uses? For each feature? What kind of objective evidence? What if I’m using software to automate test scripts? Do I have to qualify the testing software? Turning to guidance and standards for a “standard” set of practices can add to the confusion. Even within just the medical device industry, there are multiple regulations and standards that use similar and at the same time, slightly different concepts and terminology. Examples include the IQ/OQ/PQ (Installation Qualification / Operational Qualification / Performance Qualification) analogy from process validation, black box testing, unit testing, just to name a few.
Before getting overwhelmed, take a breath and read on to point #2.
While the multiple regulations and standards around software validation cause confusion, they are also a good place to start. I say that because at a high level they are trying to achieve the same thing- software that meets its intended use and maintains a validated state. Keeping the intent in mind can make it easier (at least it does for me) to see the similarities in the lower-level requirements between any terminology differences and not be as focused on making all the terminology match.
The 3rd guidance is relatively new, a draft guidance released in September, 2022, Computer Software Assurance for Production and Quality System Software. While in draft form, the final form for most guidance typically mirrors the draft document. The 2022 supplements the 2002 guidance, except it will supersede Section 6 (“Validation of Automated Process Equipment and Quality System Software”). It is also in this guidance that the FDA uses the term computer software assurance and defines it as a “risk-based approach to establish confidence in the automation used for production or quality systems.”
Once you’ve grounded yourself in one set, then you can compare and add on, as necessary, requirements for other regulatory jurisdictions. Again, focus on specific requirements that are different and where the high-level intent is similar. For example, in the EU, Regulation (EU) 2021/2226 outlines when instructions for use (IFUs) may be presented in electronic format and the requirements for the website and eIFUs presented.
#3. Start on the intended use and make your software validation and computer software assurance activities risk based.
Start with documenting the intended use of the software and associated safety risk if it were to fail. Then define the level of effort and combination of various software validation activities commensurate with the risk. Software and software features that would result in severe safety risk if it fails are to be validated more rigorously and have more software assurance activities than software that poses no safety risk.
Here are some examples of intended use and the associated safety risk.
Example 1: Jama Connect®, Requirements Management Software
Intended Use: The intended use of Jama Connect is to manage requirements and the corresponding traceability. The following design control aspects are managed within Jama Connect, user needs, design inputs, and traceability to design outputs, verification and validation activities. Risk analysis is also managed in Jama Connect.
Feature 1 Intended Use: Jama Connect provides visual indicators to highlight breaks in traceability. For example, when a user need is not linked to a design input, or vice versa.
Risk-based analysis of Feature 1: Failure of the visual indicator would result in the possibility of not establishing full traceability or missing establishment of a design control element like a design input. This risk is considered moderate as manual review of the traceability matrix is also performed as required by the Design Control SOP. Reports are exported from Jama Connect as pdfs, reviewed externally to the software, and then approved per the document control SOP.
Example 2: Imbedded software in automated production equipment
Intended use: The intended use of the software is to control production equipment designed to pick in place two components and weld them together.
Risk-based analysis: This is a critical weld that affects patient safety if not performed to specification. Thus, the software is considered high risk.
#4. Software Validation and computer software assurance is just one part of the software life cycle… you need to be concerned about the whole lifecycle.
There is more to software development and management than just the validation. Incorporate how custom software will be developed, how purchased software will be assessed to determine the appropriate controls based on risk, including verification and validation activities, and revision controlled.
#5. Have different procedures and practices for the different types of software.
This is a good time to consider how different types of software in your organization will be managed, and it’s not a one-size fits all approach. A best practice is to have separate practices and procedures; one for software in a medical device (SiMD) and software as a medical device (SaMD) and at least one other procedure and set of practices for other software, like software used in the production of a device, software in computers and automated data processing systems used as part of medical device production, or software used in implementation of the device manufacturer’s quality system.
Closing
Stay tuned for Part 2 of this 2-part blog series, where we’ll dive deeper into computer software assurance, highlight the risk-based approach, and provide tips and tools to manage your software in a compliant and efficient manner.
Jama Software is always looking for news that would benefit and inform our industry partners. As such, we’ve curated a series of customer and industry spotlight articles that we found insightful. In this blog post, we share an article, sourced from EURACTIVE, titled “The AI Act’s Fine Line On Critical Infrastructure” – originally authored by Luca Bertuzzi on February 8, 2023.
The AI Act’s Fine Line On Critical Infrastructure
As EU policymakers make progress in defining an upcoming rulebook for Artificial Intelligence, the question of to what extent AI models employed to manage critical infrastructure should be covered by tight requirements still remains open.
The AI Act is reaching a critical stage in the legislative process, with the European Parliament set to reach a common position in the coming weeks. The legislative proposal is the world’s first attempt to put in place a comprehensive set of rules for Artificial Intelligence based on its potential risks.
A critical aspect of the draft law is the category of AI models that can cause significant harm, which must comply with stricter obligations regarding quality and risk management. However, concerning critical infrastructure, how to assess risk remains a matter of debate.
AI in critical infrastructure
Artificial Intelligence is increasingly employed in managing critical infrastructure, notably for project development, maintenance and performance optimization.
An example on the construction side is Sweco Netherlands, an engineering consultancy company tasked to extend the light-rail system of Bybanen, Norway’s second-largest city, considering the existing tram lines, adjacent roads, cycle lanes, pedestrian zones and surrounding public areas.
To put together these different factors, Sweco NL used a digital twin model to visualise its project and understand how design changes would impact the timeline, costs and surroundings. The company estimates it reduced construction errors by 25% as a result.
Another area of application for this technology is dams. In 2017 HDR, a US construction company, applied machine learning to a dam’s digital twin model to simulate how the infrastructure would be affected by changes like natural shifting and erosion of the surrounding soil over time.
The model allowed dam operators to detect anomalies like cracks with an accuracy of two centimeters, differentiating them from harmless algae growth, and taking corrective measures before they grew into more significant problems.
The original AI Act proposal noted that “it is appropriate to classify as high-risk the AI systems intended to be used as safety components in the management and operation of road traffic and the supply of water, gas, heating and electricity.”
In the EU Council of Ministers, member states clarified that the concept of the safety component should be distinguished by the management system itself. In other words, in a dam, the mechanism to open the volts is the management system, whilst the technology that monitors the water pressure is a safety component.
In the European Parliament, the MEPs spearheading the work on the AI Act proposed to differentiate the management of traffic on roads, rail and air, from supply networks like water, gas, heating, energy and electricity, in compromise amendments obtained by EURACTIV.
While the Council included digital infrastructure like cloud services and data centres in the list of high-risk use cases, since the intent is to prevent “appreciable disruptions in the ordinary conduct of social and economic activities”, EU lawmakers have so far not done so.
The addition to the high-risk list caused significant anxiety in the telecom industry, which uses AI to manage network capacity, plan upgrades, detect frauds and improve energy efficiency. The question is whether the malfunction of any of these algorithms might bring the whole system down.
For example, if a telecom operator miscalculates traffic peaks in different areas of its network, would that lead to internet outages? A representative of telecom operators told EURACTIV they are not aware of any situation where that occurred, branding the issue as ‘highly hypothetical’.
More generally, critical infrastructure operators are concerned that, by casting the high-risk category of the AI regulation too wide, they might be precluded from useful tools that contribute to making their systems more efficient and secure.
A case in point is that member states excluded AI-powered cybersecurity tools from the definition of safety component.
Anti-virus malware analysis is based on predictive models and machine learning, meaning critical infrastructure service providers would have been precluded from using virtually all commercially available anti-viruses.
At the same time, AI-powered management systems are not without risks. Kris Shrishak, a technologist at the Irish Council for Civil Liberties, made the case of India in 2012 when a miscalculation of the electric grid’s peak traffic led to perhaps the largest blackout in history.
Therefore, the argument for a more granular approach in the high-risk categorisation relates to when the AI solutions make the infrastructure safer and if their failure does not entail an imminent threat.
Physical maintenance, for instance, is often costly and time-consuming, which might lead to infrastructures falling into disrepair. Not employing AI’s capacity to identify patterns and spot anomalies before they develop into bigger problems can also come at a cost.
Last year, amid the Russian-prompted energy crisis, France, usually Europe’s largest energy exporter, became a net importer as a record number of its nuclear reactors were put out of service due to maintenance stoppages.
Revolutionizing the Supply Chain: Developments in the Warehouse Robotics Industry
Warehouse robotics is witnessing steady growth, driven by the increasing adoption of automated solutions in storage for food and beverages, consumer goods, retail, and third-party logistics. The collaboration between the e-commerce sector and warehouse robotics is also a major driver of this market, as it allows for developing increasingly sophisticated warehouse automation systems. Additionally, the advent of autonomous mobile robots (AMRs) and the rising popularity of automated guided vehicles (AGVs) are also fueling the growth of this market.
Reforming Warehouse Operations: Increasing Adoption of AMRs and AGVs
One of the most notable trends in the warehouse robotics market is the increasing adoption of AMRs and AGVs. These robots are allowing for the development of more efficient and cost-effective warehouse operations, as they can automate tasks such as picking, packing, and transporting goods. Additionally, the use of AMRs and AGVs is also allowing for the development of more flexible and scalable warehouse operations, which can better meet the changing needs of businesses.
Efficient and Cost-effective: Rising Collaboration between eCommerce Sector and Warehouse Robotics
Another major trend in the warehouse robotics market is the increasing collaboration between the e-commerce sector and warehouse robotics. This is being driven by the growing demand for efficient and cost-effective warehouse operations, as e-commerce businesses look to keep pace with the rapid growth in online sales. Additionally, the use of warehouse robotics is also allowing e-commerce businesses to better meet the changing needs of their customers by providing faster and more accurate delivery of goods.
Advanced Automation: Increasing Preference for Advanced Robots in Warehouses
As the warehouse robotics market continues to evolve, it is clear that there will be a growing demand for advanced robots in warehouses. This is being driven by the surge in the adoption of robots during the COVID-19 outbreak, as businesses look to automate their operations and reduce their dependence on human labor. Additionally, the increasing adoption of industrial automation and control solutions is also contributing to the growth of this market.
Global Perspective: North America to Lead, Europe to hold Second Largest Share
The warehouse robotics market is a global industry, and it is clear that different regions are at different stages of development. Currently, North America is the largest market for warehouse robotics, driven by the rapid adoption of warehouse automation and the presence of major players in the market such as the United States. However, Europe is expected to hold the second-largest market share, driven by the rising adoption of industrial automation and control solutions in the region.
Innovations in Warehouse Automation: A Look at Leading Players’ Latest Developments
The warehouse robotics market is a highly competitive industry with several leading players. Some of the major players in the market include KUKA AG, FANUC Corporation, ABB, and Yaskawa Electric Corporation. These companies have made significant investments in the development of warehouse automation solutions and have a strong presence in the market.
Additionally, there are also several startups and smaller companies that are emerging in the market, such as Locus Robotics and GreyOrange, which are focusing on specific areas of warehouse automation. The competitive landscape is expected to become more intense with the entry of new players and increasing investments in the development of warehouse automation solutions.
In the warehouse robotics market, major players such as Kuka AG, FANUC Corporation, and ABB Limited have been focusing on developing advanced robots for warehouse automation. Recently, Kuka AG announced the launch of its new autonomous mobile robot, LBR iiwa, which is designed for use in the logistics and manufacturing sectors. Similarly, FANUC Corporation has introduced its new autonomous mobile robot, CRX-10iA, which is designed for use in the logistics and distribution sectors.
ABB Limited has also recently launched its new autonomous mobile robot, YuMi, which is designed for use in small parts assembly and other applications in the manufacturing sector. These advancements by leading players demonstrate the increasing focus on developing advanced warehouse automation solutions in the market.
![[Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System](https://www.jamasoftware.com/media/2023/03/Cybersecurity-Risk-RM-.png "[Webinar Recap] Why it Makes Sense to Store Cybersecurity Risk Management Items Inside a Requirements Management System")
![[Webinar Recap] Launch Your Aerospace & Defense Product Development Processes with Jama Connect®](https://www.jamasoftware.com/media/2023/03/BLOG-RECAP-Launch-Your-AD-Product-Development-Processes-with-Jama-1-1.png "[Webinar Recap] Launch Your Aerospace & Defense Product Development Processes with Jama Connect®")
