Tag Archive for: Compliance & Regulation

MOSA

A Nod To MOSA: Deeper Documenting of Architectures May Have Prevented Proposal Loss

Lockheed loses contract award protest in part due to insufficient Modular Open Systems Approach (MOSA) documentation.

On April 6th the GAO handed down a denial to Sikorsky-Boeing proposal protest of the Army tiltrotor award to Textron Bell team. This program is called the Future Long Range Assault Aircraft (FLRAA) which is supposed to be a replacement for the Blackhawk helicopter. In reading the Decision from the GAO, it is apparent that there was a high degree of importance placed on using a Modular Open Systems Approach (MOSA) as an architecture technique for the design and development. For example, the protest adjudication decision reveals, “…[o]ne of the methods used to ensure the offeror’s proposed approach to the Future Long-Range Assault Aircraft (FLRAA) weapon system meets the Army’s MOSA objectives was to evaluate the offeror’s functional architecture.” Sikorsky failed to “allocate system functions to functional areas of the system” in enough detail as recommended by the MOSA standard down to the subsystem level which is why they were given an Unacceptable in the engineering part of their proposal response.

MOSA will enable aerospace products and systems providers to not only demonstrate conformance to MOSA standards for their products but allow them to deliver additional MOSA-conformant products and variants more rapidly. By designing for open standards from the start, organizations can create best-in-class solutions while allowing the acquirer to enable cost savings and avoidance through reuse of technology, modules, or elements from any supplier via the acquisition lifecycle.

Examining MOSA

What is a Modular Open Systems Approach (MOSA)?

A Modular Open Systems Approach (MOSA) is a business and technical framework that is used to develop and acquire complex systems. MOSA emphasizes the use of modules that are designed to work together to create a system that is interoperable, flexible, and upgradeable. To do this MOSA’s key focus is designing modular interface commonality with the intent to reduce costs and enhance sustainability efforts.

More specifically, according to the National Defense Industrial Association (NDIA), “MOSA is seen as a technical design and business strategy used to apply open system concepts to the maximum extent possible, enabling incremental development, enhanced competition, innovation, and interoperability.”

Further, on January 7, 2019, the U.S. Department of Defense (DoD) issued a memo, signed by the Secretaries of the Army, Air Force, and Navy, mandating the use of the Modular Open Systems Approach (MOSA). The memo states that “MOSA supporting standards should be included in all requirements, programming and development activities for future weapon system modifications and new start development programs to the maximum extent possible.”

In fact, this mandate for MOSA is even codified into a United States law (Title 10 U.S.C. 2446a.(b), Sec 805) that states all major defense acquisition programs (MDAP) are to be designed and developed using a MOSA open architecture.

MOSA has become increasingly important to the DoD where complex systems such as weapons platforms and communication systems require a high level of interoperability and flexibility. Their main objective is to ensure systems are designed with highly cohesive, loosely coupled, and severable modules that can be competed separately and acquired from independent vendors. This allows the DoD to acquire systems, subsystems, and capabilities with increased level of flexibility of competition over previous proprietary programs. However, MOSA can also be applied to other industries, such as healthcare and transportation, where interoperability and flexibility are also important considerations.

The basic idea behind MOSA is to define architectures that are composed of more, more manageable modules that can be developed, tested, and integrated independently. Each module is designed to operate within a standard interface, allowing it to work with other modules and be easily replaced or upgraded.

RELATED: Streamlining Defense Contract Bid Document Deliverables with Jama Connect®

The DOD requires the following to be met to satisfy a MOSA architecture:

  • Characterize the modularity of every weapons system — this means identifying, defining, and documenting system models and architectures so suppliers will know where to integrate their modules.
  • Define software interfaces between systems and modules.
  • Deliver the interfaces and associated documentation to a government repository.

And, according to the National Defense Authorization Act for Fiscal Year 2021, “the 2021 NDAA and forthcoming guidance will require program officers to identify, define, and document every model, require interfaces for systems and the components they use, and deliver these modular system interfaces and associated documentation to a specific repository.”

  • Modularize the system
  • Specify what each component does and how it communicates
  • Create interfaces for each system and component
  • Document and share interface information with suppliers

MOSA implies the use of open standards and architectures, which are publicly available and can be used by anyone. This helps to reduce costs, increase competition, and encourage innovation.

Why is MOSA important to complex systems development?

MOSA, an important element of the national defense strategy, is important for complex systems development because it provides a framework for developing systems that are modular, interoperable, and upgradeable. Here are some reasons why MOSA is important:

  • Interoperability: MOSA allows different components of a system to work together seamlessly, even if they are developed by different vendors or organizations. This means that the system can be upgraded or enhanced without having to replace the entire system.
  • Flexibility: MOSA promotes the use of open standards and architectures, which allows for greater flexibility in system development. It also allows for more competition among vendors, which can lead to lower costs and better innovation.
  • Cost-effectiveness: MOSA can reduce costs by allowing organizations to reuse existing components or develop new components that can be integrated into existing systems. It can also reduce the cost of maintenance and upgrades over the lifecycle of the system.
  • Futureproofing: MOSA allows for systems to be upgraded or modified over time, as new technology becomes available. This helps to future-proof the system, ensuring that it can adapt to changing needs and requirements.

RELATED: Digital Engineering Between Government and Contractors

How can Live Traceability™ in Jama Connect® help with a MOSA?

Live Traceability™ in Jama Connect® can help with MOSA by providing mechanisms to establish traces between MOSA architecture elements and interfaces, and the requirements and verification & validation data that support them. Live Traceability is the ability to track and record changes to data elements and their relationships in real-time. This information can be used to improve documenting system design, identify potential issues, and track changes over time.

Here are some specific ways that Live Traceability can help with MOSA:

  • Status monitoring: Live Traceability allows systems engineers to monitor the progress of architecture definition in real-time, identifying issues from a requirements perspective as they arise. This can help to increase efficiency and ensure that the stakeholders are aware of changes as they occur.
  • Digital Engineering: Live Traceability can help with digital engineering by providing mechanisms to capture architectures, requirements, risks, and tests including the traceability between individual elements.
  • Configuration and Change Management: Live Traceability can help with change management by tracking changes to system architectures and interfaces including requirements that are allocated to them. This can help to ensure that changes are properly documented and that they do not impact other parts of the system. Baselining and automatic versioning enable snapshots in time that represent an agreed-upon, reviewed, and approved set of data that have been committed to a specific milestone, phase, or release.
  • Testing and Validation: Live Traceability can help with verification and validation to ensure that system meets specified requirements and needs. This can help reduce risk by identifying issues early in the development process and ensuring that the system meets its requirements.
  • Future-proofing: Live Traceability can help to future-proof the system by providing a record of system changes and modifications over time. This can help to ensure that the system remains flexible and adaptable to changing needs and requirements.

In summary, Live Traceability in Jama Connect can help with MOSA by providing real-time visibility into the traceability between architectures, interfaces, and requirements. It can help to improve documenting the system design, identify potential issues, and track changes over time, which are all important considerations for MOSA.


TMF

What is a Trial Master File in the Medical Device Industry?

A Trial Master File, also known as a TMF, is a collection of records and documentation about the creation, evaluation, and regulatory approval of a medical device. It shows the quality control procedures used in the device’s design, production, and testing to make sure it meets all applicable regulations. Regulators look at the TMF during inspections and audits to see if the device is in compliance.

How is a Clinical Trial Master File (TMF) similar to a Trial Master File?

A Clinical Trial Master File (TMF) is similar to a Trial Master File in that they are both collections of documents and records related to a specific project. However, while a Trial Master File pertains to the development, testing, and regulatory approval of a medical device, a Clinical Trial Master File pertains to the clinical trials conducted to evaluate the safety and efficacy of a medical device, pharmaceutical product, or treatment.

Both types of TMFs provide evidence of the processes and procedures used during the development and testing phases, and both are subject to review by regulatory agencies during inspections and audits.

What is an Electronic Trial Master File?

An Electronic Trial Master File (eTMF) is an electronic version of TMF that stores documents and records generated during the clinical trial process. eTMFs can replace paper-based TMFs and provide a more efficient and effective way to manage the vast amount of information generated during a clinical trial. Using an eTMF is becoming more common in the clinical trial industry due to its many benefits over paper-based TMFs, including improved efficiency, increased security and accessibility, and enhanced regulatory compliance.

To achieve compliance, organizations need defined processes for development and production and detailed traceability, from the high-level user needs through to test management. Documentation is a large part of proving compliance, and Jama Connect® makes it easy to compile the necessary documentation, like eTMFs. By automating the process, teams can focus on what’s important and avoid potential errors.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

What types of regulations are TMFs or eTMFs expected to meet?

Both Clinical Trial Master File (TMF) and Electronic Trial Master File (eTMF) must adhere to various regulatory requirements depending on the jurisdiction in which the clinical trial is conducted. Some of the common regulations that a TMF or eTMF must comply with include:

  • International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) guidelines: This is a set of global guidelines for the development, registration, and post-approval of pharmaceuticals.
  • Good Clinical Practice (GCP) guidelines: This is an international ethical and scientific quality standard for designing, conducting, recording, and reporting clinical trials that involve the participation of human subjects.
  • The Food and Drug Administration (FDA) 21 CFR Part 11: This is a regulation that establishes the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records.
  • Health Insurance Portability and Accountability Act (HIPAA): This is a US federal law that requires the protection and confidential handling of personal health information (PHI) stored in electronic form.
  • European Union Clinical Trials Regulation (EU CTR): This is a regulation that governs the conduct of clinical trials in the European Union and aims to harmonize the regulatory requirements across EU Member States.

How can a TMF help an organization with successful product development and management?

It is important for the trial sponsor, sponsor’s representative or the CRO to ensure that the TMF or eTMF meets all relevant regulatory requirements to ensure the integrity and quality of the clinical trial data.

A Clinical Trial Master File (TMF) can help an organization with successful product management by providing a centralized repository of all the relevant documentation and information related to the development and testing of a product. The TMF helps to ensure that all necessary documentation is captured and easily accessible, which can help to:

  • Streamline the development process
  • Ensure regulatory compliance
  • Improve collaboration and communication
  • Facilitate post-market monitoring

RELATED: [Webinar Recap] An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)

Overall, a well-managed TMF can play a critical role in the successful development, testing, and management of a product, by providing a comprehensive and centralized record of all relevant information and documentation.

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


FDA

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 moving ahead with rulemaking on lab developed tests without waiting for Congress: BioWorld” – originally authored by Nick Paul Taylor and published on March 2, 2023.

FDA Moving Ahead with Rulemaking On Lab Developed Tests Without Waiting for Congress: BioWorld

FDA headquarters in White Oak, Maryland. Sarah Silbiger/Getty Images via Getty Images

Dive Brief:

  • The U.S. Food and Drug Administration is “moving forward with rulemaking” on laboratory developed tests (LDTs) without waiting for new powers from Congress, a senior FDA official said at an industry conference.
  • Elizabeth Hillebrenner said on a panel Wednesday that the agency cannot “just stand by” given the perceived public health problem created by LDTs and the failure of Congress to pass legislation.
  • The FDA has yet to set a timeline for LDT rulemaking or provide a close look at its plans, Hillebrenner said, noting that the agency will follow a three-tier risk framework, but giving few other details.

RELATED: Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I

Dive Insight:

Lawmakers have been trying to pass LDT legislation for years. An earlier form of the Verifying Accurate Leading-Edge IVCT Development (VALID) Act was introduced to Congress in 2018. Key aspects of the draft advanced as part of the FDA’s user fee package last year, only to be cut from the final version. A push to pass the VALID Act as standalone law fell short late last year.

The FDA identified a need to reconsider its policy of enforcement discretion for LDTs in 2010, reflecting the increasing complexity and risks of the tests, and shared a discussion paper in 2017. However, the paper is not enforceable.

RELATED: 2023 Predictions for Medical Device Product Development

Legislation would clarify the FDA’s authority to regulate LDTs and give the agency new powers, but in the ongoing absence of action from Congress, work is now advancing under the current statutory authority. Hillebrenner, associate director for scientific and regulatory programs at the FDA’s Center for Devices and Radiological Health, outlined the situation at an American Clinical Laboratory Association event.

In comments reported by BioWorld, Hillebrenner noted that FDA Commissioner Robert Califf “has already said all options are on the table, including rulemaking, and we are moving forward.” The FDA continues to support legislation such as the VALID Act that provides a regulatory framework in line with modern diagnostics but is no longer willing to wait on Congress to address the problems posed by LDTs, she said.


EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR)

In this blog, we recap the “An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Diagnostics Regulation (IVDR)” webinar.

Looking to stay ahead of ever-evolving regulations governing medical devices?

In this webinar, we discuss the continual rollout of the EU Medical Device Regulation (MDR) and In-Vitro Device Regulation (IVDR) and the impact they’re having on the medical device industry.

Vincent Balgos, Director of Medical Device Solutions at Jama Software and Saby Agai, Sr. Consultant at Jama Software, provide a high-level overview of the new regulations, along with general industry observations and future considerations for organizations with medical products marketed in the EU market area, including:

  • New classifications, grandfathering clause, and risk management requirements
  • The number of notified bodies, backlog, and remediation efforts for placed products
  • Future considerations regarding the compliance compatibility of IVDR & FDA and traceability
  • Finally, learn how the Medical Device Framework in Jama Connect® can help streamline your compliance efforts and ensure your products meet all the necessary regulatory requirements.
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

Saby Agai: So, in the first part of the webinar we will talk about the EU medical device regulations. There is a small agenda to that. Basically, we would like to show the key changes and challenges that the MDR means compared to the MDD. We would also like to talk a little bit about what we see as the challenges for the process transformation of the medical device developers and also a bit of discussions with the race on the timeline for the MDR. The second section is on the MDR for the MedDev engineering. So basically, how the engineering teams can do anything with the MDR. We’ll talk about harmonized standardization. How does that fit in the concept of the MDR? And some of the medical device best practices that we would recommend. So the medical device regulations now has quite a bit of history because the MDR is valued also for existing [inaudible 00:04:15] devices and also for all the new devices.

The medical device regulations entered into force historically in May 2017, and there was a bit of extension period in 2020 that the certificates issued under the MDD before the MDR remained valid up to four additional years. So it was a bit of a time extension for manufacturers to migrate the legacy devices to the MDR. Recently 2023, the EU commission had the new rule based on 607 was the number of it on the time extension for the medical device regulations. So there are two-time extension now in force for December 2027 and 2028 for all devices. As part of this modification, the commission removed the sale of period from the original context of the Medicaid device regulation.

Three key area that we would mention that we see as key challenges with the MDR is first is the technical documentation. So because of the legacy medical devices has to be reclassified in a context of the new MDR, those manufacturers highly likely will face it extended set of documentation for market clearances in the EU. It’s particularly true for software as a medical device because, basically the class one level has removed by legislation for all software as a medical device. The other thing on the technical documentation is that the MDR is far more prescriptive about the requirement content of the technical documentation, and it’s particularly true and there are more detailed requirements needed for the quality management system. So the manufacturer will have to ensure that they not only have full access and control for the documentation of the device, but also they should keep the eye on the market and the vigilance market, post-market vigilance area, as well as publication or new common specifications.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Agai: So there is a bit of higher focus on the post-market activities in the context of the MDR. And the technical documentation basically has two key parts in Annex II, annex III it’s detailed. Annex II there is a list of requirements for the technical documentation itself for the device design, and also, in Annex III, we see details or requirements for technical documentation post-market surveillance. So nothing particularly new, only an extended set of expectation and requirements for all these contents. Little note something on the technical documentation. So historically, the technical documentation has a tradition to be seen as a burden on the med tech developers and additional administrative work. And quite often, at the end of the development cycle, there is a massive effort made to make what is documentation available for regulators and also for market clearance. It definitely could require very intense administrative work from the engineering sometimes stress involved and also, the content creation has not much help or not much support for the regional engineering activities, which is the development.

So these content created purely to support the market access activities and it should not necessarily should be a case, though. So, for example, we in Jama has a medical solution. It’s a example proven a tool actually can support both med tech developers to enhance the development efficiency as they develop a new device as well as to support these technical documentation needs at the same time. So it’s a opportunity also for organizations to get most out of using a tool when they thinking about to ease the burden of the medical device regulation technical documentation part.

RELATED: Jama Connect® Validated Cloud Package for Medical Device and Life Sciences

Agai: Thirdly but not lastly, there was a new, particularly in EU requirements for the unique device identifier. So basically, 2021 was a deadline to register an MDR UD MDR devices with the UDI in the [inaudible 00:09:02] framework, and for the IVDR, it’s 2022. Looking into purely on the numbers, we could say that the content of the MDR compared to the MDD is actually four time heavier. So the extent and the legal tax basically is four time more. There are five plus on axis that we can see, and there is a special attention on safety and patient safety particularly because 293 times mentioned the safety word in MDR where in the MDD was the 24. All these numbers also telling that the regulators in EU want to have higher scrutiny compared to the MDD, and they also have more details on that level of expectation that they would like to see from manufacturer. And there is a definite focus on patient safety that we can see.

Two more things to mention is that quite often, in the context of the MDR, the legacy devices should be reclassified into a higher level class. So it means that the quality management process support is more intense, and more support expected. More activities and works are expected from the manufacturer to keep the same device basically on the market. It also could mean that companies should take a step for high-level maturity as an organization and it’s true also for the design and device development activities. So one of the challenge with that is that if we talk about the same device with higher regulatory scrutiny, how do we retain and enhance profitability? Because the administrative burden is definitely something that goes towards the cost part of the profitability. So the design and development goes under higher level of process expectation in that sense, and it goes higher level of design documentation needs as well. So one of the advantages using the tool in general medical device environment that the medical solution can ease actually this work and enable a bit quicker, and the developers can leverage a little bit more help on these challenges.

To watch the entire webinar, visit
An Overview of the EU Medical Device Regulation (MDR) and In-Vitro Diagnostics Regulation (IVDR)


FDA

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

The exterior of the Food and Drug Administration headquarters is seen on July 20, 2020 in White Oak, Maryland. Sarah Silbiger via Getty Images

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.

RELATED: 2023 Predictions for Medical Device Product Development

Dive Insight:

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.

RELATED: Practical Guide for Implementing Software Validation in Medical Devices: From FDA Guidance to Real-World Application – Part I

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.


Aircraft Certification

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 Air & Space Forces Magazine, titled “Digital Transformation of Verification Process for Faster Aircraft Certification” – originally authored by Thierry Olbrechts and published on March 13, 2023.

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.

RELATED: Jama Connect® for Space Systems

Implications – Aircraft Programs at Risk

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.

Figure 1. Implications of increased program complexity and integrated systems: the current approach does not work anymore.

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.

Figure 2. Building the verification and certification Digital Twin: actively manage the plan from start to finish.

Different digital platform pillars are key in this:

Figure 3. Key technologies to support aircraft programs.

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.

RELATED: [Webinar Recap] Launch Your Aerospace & Defense Product Development Processes with Jama Connect®

Digital Data and Process Backbone

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.


Cybersecurity

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

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

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

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

Key Takeaways:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Software Validation

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.

RELATED: Understanding Integrated Risk Management for Medical Devices

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.

RELATED: Jama Connect® for Medical Device Development Datasheet

Closing

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.

To read part one of this blog, click HERE.


 

MDR

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

MDR

titoOnz via Getty Images

Listen to the article (4 min)

This audio is auto-generated. Please let us know if you have feedback.

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.

RELATED: Your Guide to the Verifying Accurate Leading-edge IVCT Development (VALID) Act

“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.

RELATED: 2023 Medical Device Product Development Predictions

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.


FuSA

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

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

What Is Functional Safety?

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

RELATED: Managing Functional Safety Development Efforts for Robotics Development

How Does FuSa Work?

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

FuSa Standards and Compliance Requirements

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

Typical Applications of FuSa

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

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

RELATED: 2023 Predictions for Industrial and Consumer Electronics Product Development

Conclusion:

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

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