In this blog, we discuss INCOSE’s System Engineering Handbook V5. To download this handbook, click HERE.
Empowering Engineers: Exploring INCOSE Systems Engineering Handbook V5
What is INCOSE?
The International Council on Systems Engineering (INCOSE) was founded as a collaborative effort to bring systems engineers together and provide them with resources to progress in their field. Their mission is to cultivate a strong network of professionals, supply educational materials, and create tools that will help systems engineers be successful. INCOSE is dedicated to elevating the global profile of the systems engineering (SE) profession.
According to INCOSE, the Systems Engineering Handbook “shows what each systems engineering process activity entails in the context of designing for affordability and performance. On some projects, a given activity may be performed very informally (e.g., on the back of an envelope, or in an engineer’s notebook); or, on other projects, a more formal response is required with interim products under formal configuration control.”
The handbook provides assistance for individuals of various backgrounds and experience levels, such as those just beginning their systems engineering journey, engineers from different disciplines needing to apply the principles of systems engineering, and experienced engineers looking for a handy reference.
INCOSE Systems Engineering Handbook V5
The newly released INCOSE Systems Engineering Handbook V5 is a comprehensive guide to the discipline of SE which outlines the current best practices and serves as an informative reference for understanding SE in terms of content and application.
Some of the topics included in the latest handbook include:
Elaboration on the key systems life cycle processes described in ISO/IEC/IEEE 15288:2023;
Chapters covering key systems engineering concepts, system lifecycle processes and methods, tailoring and application considerations, systems engineering in practice; and
Appendices, including an N2 diagram of the systems engineering processes and a detailed topical index.
Applying INCOSE Standards Using Jama Connect Advisor™
System engineers focus on making each of the individual systems work together into an integrated whole that performs as expected across the lifecycle of the product. In order to deliver successful products, they need the right user needs and requirements. Efficient, precise, and professionally written requirements form the foundation of the product development process so that various teams (design, software, and hardware systems) can all work together with a shared and clear understanding of the project goals.
Jama Connect Advisor™ is a state-of-the-art requirements authoring guide and optimizer powered by natural language processing for engineering that helps a system engineer or a product developer write effective, well-organized requirement specifications based on industry-accepted INCOSE rules and the EARS (Easy Approach to Requirements Syntax) notation.
In this blog, we recap our webinar, “Effectively Managing Cybersecurity in Jama Connect® for Automotive and Semiconductor Industries”. Click HERE to watch the entire thing.
If you’re in the automotive or semiconductor industries – cybersecurity is likely top of mind.
In this webinar, attendees will see exactly how to:
Define cybersecurity goals, requirements, and concepts
Conduct threat analysis and risk assessment
Establish traceability to the architecture design and verification/validation of cybersecurity measures
Document the cybersecurity case and manage changes
Identify and classify assets for the subject of the cybersecurity case
Discover how Jama Connect can help you optimize your cybersecurity processes and stay ahead in the Automotive and Semiconductor industries.
Below is an abbreviated transcript of our webinar.
Effectively Managing Cybersecurity in Jama Connect® for Automotive and Semiconductor Industries
Kevin Dibble: Well, first I’m going to talk about what we’re going to talk about, so these are the topics that we’re going to cover. And without reading this slide, really we’re going to cover the development life cycle of creating, the example we’re going to use is a 48-volt power assist system. You might also think of it as a battery management system. And so I’ll go over the agenda, but what you can see on the is we’re going to cover everything from the planning in the case through the TARA work and down through the left side of the V and some of the right side of the V activities as well. And here’s how we’re going to do it. First, to get everyone oriented to 21434, we’re going to talk about the standard itself briefly and highlight some of the benefits of implementing a cybersecurity case in a tool, in a requirement management tool.
Then we’ve got some workflows to look at, the steps of the development life cycle for 21434 from the perspective of an OEM and then again from the perspective of a tier one. And then Matt is going to show the work products, the traceability, and what we’ve talked about at the beginning actually in the tool in a built-out project for a 40 volt power assist system. And then we’ll finish with some takeaways. So that’s what’s on tap for today. And so I want to make the case for managing cybersecurity and the cybersecurity case and the work products in a requirements management tool. So I’m going to just look at each one of these points. The first item is to improve collaboration between OEMs, tier ones, and tier twos.
Jama Connect supports ReqIF, which can be used for bidirectional communication of requirements, item definitions, et cetera, as well as updates to those assets. And so it supports better collaboration. One thing that Jama promotes is this idea of trace as you go. So traceability is not an afterthought handled by a requirement engineer at the end of the project that takes weeks to implement on a complex project. It’s something that the engineers are doing as they’re creating the requirements tracing to parent requirements, design blocks for requirement allocation, et cetera. And so this tool supports that traces you go methodology along with some views of the progress of tracing.
Dibble: The impact analysis is a powerful tool when you trace as you go and the requirements left and right side V model assets are linked together. Then running impact analysis reports as changes come in midstream in programs, which they do in automotive for sure. You get that as a benefit. Like I mentioned earlier, requirements allocation. So allocating requirements to design blocks or interconnecting the requirement management system to design tools and doing allocation in those tools like Design Architect gives you some powerful analytics like test coverage reports automatically generated. Also connecting the tools through connectors gives you a toolchain view instead of disjointed tool. And finally, Jama Connect offers some analytics that we’ll see some of these in the demo that will give you a very clear indication of where you are in the project, especially in terms of requirements that are allocated, tests that have been covering requirements, and so on and so forth.
So with that, I’m going to orient everybody to 21434 in terms of the V model, which it’s centered on, and two other standards that you may be more familiar with. ISO 26262 and Automotive ASPICE. And so just a couple things here. If you are familiar with these other two standards, you’ll see that 21434 fits nicely alongside and that was intended by the ISO folks that did the standard. They very much aligned it with ISO 26262, and really even in nomenclature. So whereas in safety we have safety goals, in security we have security goals, in safety, we have the HARA, the hazard and risk assessment. In cybersecurity, we have the TARA, threat, and risk assessment, and so on and so forth. And also the common supporting processes like configuration management, change management, project management, document management, even confidence in use of software tools that all of these standards rely on are again repeated and required in 21434.
Dibble: So just some basic organization of the standard in terms of the V model and then we’ll look at it in one more view in terms… this is directly out of ISO. And at Jama, we’ve added some color coding and I’m going to explain that. And so if you’re not familiar with this view, 21434 is oriented by clauses and sub-clauses. And so you can see the clause here like clause five is organizational, that’s policy and tool management and quality management and things. And then clause six, et cetera, and on down, that’s how this is organized. Jama has capabilities that support these sub-clauses. And so we’ve used a color system here to highlight that. The sub-clauses that are colored in green are fully supported and in fact, recommended to implement in Jama. The yellow are optional, they could be implemented in Jama.
And for most of these, we have customers that are implementing these types of things in Jama, but they also use other systems to implement them. And then this kind of yellow-green is partially supported. Jama can support some of the requirements but not all. And then of course red is not recommended for support in Jama and it’s usually house and other tools or things like production tools, et cetera. Okay, so what Jama brings to the table in terms of capabilities to support these green and yellow items are document building and generation. So the document management functionality as well as the exporting functionality. As you’ll see in the demo, you can export what has been entered in a requirements tree or in one view can be exported into a more of a document-style view that perhaps suppliers or other people might want to consume.
It has built-in collaboration tools for reviewing, which is very important because 21434, like 26262 requires review records, and all the work products are reviewed. Traceability and impact analysis, I already talked about. VNV verification and validation with the test manager tool as well as interconnections to other tools and analytics. There’s a nice support for the right side of the V activities. Using a common tool does bring alignment between different engineering disciplines, whether it’s hardware, software in systems, or if it’s QA tests and V&V activities versus development activities. Release planning and coverage through dashboards and status metrics and then of course baselining and reuse and whatnot.
And so this slide shows all of the items from the previous slide that were recommended or are optional and just shows how they would look in a project tree format. Again, Matt’s going to go through most of these items for our 48-volt power assist item that we’ve built out. Okay, one of the important features of Jama Connect as well as any requirement management tool is the ability to develop traceability. Here we’re showing the traceability model, which is their traceability models come with the product, but they also can be customized. And then I’ve got a little animation here to show for cybersecurity, some of those standard parts and tying them back to the standard. So for instance, in the model, I don’t know, it’s small print, but you can probably see cybersecurity asset, attack path, damage scenario, threat scenario. Those all correspond to the TARA and here are the sections that those are discussed in.
Curious to learn how the Medical Device Framework in Jama Connect® can help streamline your compliance efforts and ensure your products meet necessary regulatory requirements?
During this informative session, Vincent Balgos, Director of Medical Device Solutions at Jama Software® discusses the latest solution offerings for Medical Device and Life Sciences in Jama Connect, including:
Updated Software as Medical Device (SaMD) framework incorporating readily available off-the-shelf elements for workflow and efficiency
Newly developed Research Use Only (RUO) and In-Vitro Diagnostics (IVD) frameworks
Refined solution enhancements, including new and updated report templates
Self-guided onboarding framework to assist new users in Jama Connect
Discover how Jama Connect can help you optimize compliance and regulatory processes, helping you stay ahead in the constantly evolving medical device industry.
Below is an abbreviated transcript and a recording of our webinar.
Elevating Your Medical Device and Life Sciences Product Development Processes with Jama Connect®
Vincent Balgos: For today’s webinar, I’d like to talk about our updates to our Medical Device and Life Sciences Solution 2.0. For the agenda, there are quite a few improvements I’d like to share with you today. The first one is really just kind of talking about general overview and general improvements in terms of risk, some new features that we’ve enabled with Jama Connect, but also some new and updated solutions such as Software as a Medical Device, Research Use Only, and our new self-guided onboarding framework.
So the intent of the update is to continually improve Jama solution to the medical device and life sciences industries based on a variety of factors, including new Jama Connect features and abilities that help streamline general product development processes and industry best practices. Also adapts to the ever-evolving regulations such as MDR, IVDR, and potential changes to the lab developed test area. We’ll talk about more of this in the ROU space. We’ve also included internal research and internal experience with over 80 years of industry experience from the internal Jama team. And lastly, we’ve also incorporated some feedback from customers like yourselves on best practices, innovative solutions, and new use cases. So thank you ahead of time and please continue to contribute via the Jama Community Ideation page or discussion with Jama folks.
These solutions that are presented are compatible and available with Jama Connect for both our cloud customers, both the standard and validated, and our self-hosted environments. Some highlighted features may require version updates, and this is really particular to our self-hosted customers with legacy versions.
Balgos: So what I’d like to first talk about is the general organization and layout. So what I’m going to do is come back between screens, between the PowerPoint and the actual, the demo itself.
So the first thing I want to show is the general organization and layout of our new Medical Device Framework 2.0. The first thing I want to show is when we go ahead and take a look, you’ll see here in this new folder we have something enumerated Medical Device Framework 2.0, that actually has our new Medical Device Framework and our other additional popular framework such as SAMD and Consumables Framework.
The other folder to mention is really kind of our new use case library that highlights additional use cases that we’ve seen across our 300 plus customers and their practices using Jama Connect. We’ll deep dive into each one of these very shortly. We’ve also archived the current… sorry, the previous Medical Device Framework 1.0 for your reference only.
So now let’s go ahead and dive into the overview of the MDF 2.0. So I’m going to jump into the tool. And as you can see here right on the screen, we’ve updated the relationship rule diagram with some minor improvements. The first thing we’ve done is really streamline the risk stream where we remove the validation trace and trace this now to an external resource item type. The purpose of this item type is a general documentation catch call for a lot of various traces that you may have. The most common example is associated with risk. So as many of you may know, not all risk controls are requirements. So we still need a way to trace to these non-requirement risk controls. These controls could be IFUs or instructions for use, training, labeling, or labeling and packaging, et cetera, and may vary depending on your risk management procedures. This provides additional risk coverage traceability that provides flexibility for your organization.
Balgos: Another thing that we’ve done is actually updated our hazards library to include general hazards identified in 14971. As you can see here on the screen, we’ve now populated the general hazards identified in 14971 based on the information that you have. So you have pretty much a starting place with your hazard library that you have here.
The next item that I’d like to talk about is actually this new feature called the Risk Lookup Matrix. Available in 8.754, this features allows a new lookup matrix risk analysis approach that automatically outputs the desired content based on a pre-configured lookup table. This really aligns with 14971. Let me show you a quick demo of this because we’ve now implemented this as part of our Medical Device Framework 2.0.
Balgos: As you can see here on the screen, I have a new item type called Risk Evaluation 2.0 that kind of, again, follows the general 14971 schema of hazardous sequence of events, hazardous situations harmed. But here is now where we’ve implemented this new lookup matrix feature where now I’ve now identified the input pick lists where I may be able to change this, and then that automatically updates my risk level based off that matrix. So for example here, if I went ahead and increases the frequency and I increase my severity from here over here, and this one as well, I can see that both my P total and risk analysis has been updated per the lookup matrix. We have an additional features [inaudible 00:07:27] video that showcases a little bit more. So we definitely encourage you to look at that further.
The other thing that we wanted to share with particularly this medical device update is we have now included pre-configured FMEA item types for ease of implementation for your risk processes. If I go ahead and look into my admin area, what I mean by this is when I look at my item type, I’ve now included pre-configured DFMEAs, process FMEAs, and use FMEAs that you may configure based on your organization. This just allows for streamlining of your risk measures processing quickly to Jama Connect.
https://www.jamasoftware.com/media/2023/07/2023-Webinar-Recap-Med-Update.png5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2023-07-13 03:00:242024-01-17 23:51:58[Webinar Recap] Elevating Your Medical Device and Life Sciences Product Development Processes with Jama Connect®
In this blog, we recap the “New Research Findings: The Impact of Live Traceability™ on the Digital Thread” webinar.
Examine new industry research that highlights the reasons for the growing interest in digital thread and learn how Live Traceability™ enables the digital thread to reduce risk, save cycle time, and improve product quality.
The digital thread is a measurable data-driven architecture that links together information generated from across the product lifecycle and is envisioned to be the primary or authoritative data and communication platform for a company’s products at any instance of time.
During this session, James Roche, Practice Director of Aerospace & Defense at CIMdata, Inc and Cary Bryczek, Director of Aerospace & Defense Solutions at Jama Software®, report on key findings from recent research on digital thread conducted by CIMdata on behalf of the Aerospace and Defense PLM Action Group — and in collaboration with Jama Software and other solution providers. The shared objective of this research was to gain an understanding of the needs and opportunities within industry that will inform digital thread solution strategies and roadmaps and guide industrial implementations.
Finally, learn how Jama Software’s industry-leading platform, Jama Connect®, helps teams manage requirements with Live Traceability across the systems development process for proven cycle time reduction and quality improvement.
Below is an abbreviated transcript and a recording of our webinar.
New Research Findings: The Impact of Live Traceability™ on the Digital Thread
James Roche: Thank you to Jama Software for inviting me to participate in today’s discussion of the exciting and important topic of digital thread. In this presentation, we’ll report key findings from recent research on the topic of digital thread conducted by CIMdata on behalf of the aerospace and defense PLM action group member companies in collaboration with Jama Software and other PLM solution providers. We’ll begin with an introduction of how this research came about, who sponsored it, and for what purpose. We’ll explain how the information was gathered and from whom. Then we’ll review the key findings from the research in various categories as shown here, the what and why of the digital thread, the current reality, planning future investments, and solution capability and provider alignment with the needs and strategies of their industrial customers.
I will then turn the session over to my colleague from Jama Software, Cary Bryzcek. The initiators and prime sponsors of this research are seven A&D OEMs who are the current members of the Aerospace and Defense PLM Action Group. Since its founding in 2014, the A&D PLM Action Group has sponsored research and jointly staffed projects on topics such as model-based definition, multiple-view bill of materials, PLM technology obsolescence management, global collaboration, model-based system engineering, and digital twin digital thread. The members regularly interact with the principal PLM solution providers in project collaborations and executive level strategic discussions.
Roche: The group’s leadership has recently determined to expand its reach into the PLM solution provider community, and engage in collaborative research and dialogue on strategic topics. The topic selected for this program was digital thread. We know that investment in digital thread today is real and substantial, and the level of investment will continue to rise. That reality positions digital thread as an emerging strategic opportunity within the PLM ecosystem. To invest effectively in solution development as a software provider, or solution implementation as an industrial user requires insight into current state enablers and barriers and future investment drivers.
The shared objective of this research was to gain understanding of needs and opportunities within industry that will inform digital thread solution strategy and roadmap, and guide industrial implementations. The project used two methods of gathering information, subject matter expert interviews and an online survey. Interviews were conducted by CIMdata with three communities, the participating solution providers, key A&D customers nominated by the participating sponsors, and the A&D action group member companies. The second method of information gathering was through a web-based survey targeted toward a broader community beyond practitioners in industry. The learnings from the interviews were applied to develop the line of inquiry for the web-based survey.
Roche: CIMdata conducted a total of 15 interviews, five with the solution provider sponsors, five with their key customers, and five with A&D action group members. A total of 90 complete and validated survey responses were received and have been analyzed. Review of the names of the companies represented and the positions held by the interviewees and survey respondents confirms that the information received is representative of the most influential companies and leading thinkers within the aerospace and defense industry. The survey was open to all industries, but it was targeted toward and most heavily promoted within aerospace and defense, and nearly 60% of responses were from that industry. The response distribution was evenly spread across companies’ size by revenue.
We began our interviews and the survey with an exploration of the what and the why of digital thread. The conceptual understanding of digital thread within industry is very immature. All interviews began with a question, “What is your definition of digital thread,” which yielded 15 different definitions. Nearly half of the company’s survey do not have a commonly accepted definition of digital thread, and less than 10% use the published definition. Our search for the reasons for digital thread’s rise to prominence revealed the traditional drivers such as product complexity, time to market and search for efficiencies are clearly still in play, but new realities such as rising customer expectations as evidenced in the DOD’s digital engineering strategy with an authoritative source of truth, and new enabling technologies are major drivers of the digital thread’s rise to prominence.
Among specialists, there is a broad shared perception of what digital thread does, and what a digital thread is. The most prominent characteristic of what a digital thread is and what it does relate to establishing linkages and traceability between product data. Interestingly, if you combine the most prominent characteristics of what a digital thread does, you have a reasonable definition of the digital thread, establishes traceability of product information across multiple domains in the lifecycle, mechanical, electrical or electronic software and firmware to provide meaningful relationship connections between a product’s digital assets. Our research examined the current and expanding digital thread value footprint in three dimensions, program stage, data, and use cases.
https://www.jamasoftware.com/media/2023/06/Copy-of-2023-Product-Development-Complexities_Social-Image-1.png5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2023-06-22 03:00:412024-01-17 23:57:07[Webinar Recap] New Research Findings: The Impact of Live Traceability™ on the Digital Thread
What is DevSecOps? A Guide to Building Secure Software
DevSecOps has gained popularity as a secure and dependable software development methodology in the fast-paced world of software development. But what is DevSecOps really, and why is it so crucial?
DevOps is a set of techniques that stresses collaboration and automation between development and operations teams. DevSecOps is the integration of security practices into this methodology. DevSecOps seeks to establish a security culture that guarantees the software is secure and complies with compliance standards by integrating security into every phase of the software development lifecycle, from planning through deployment.
The ability to identify and address security risks earlier in the development process is one of the main advantages of DevSecOps. This means that security is incorporated into the software at the outset instead of being added later, which can be expensive and time-consuming. Also, DevSecOps plays a big role in decreased risk of security breaches and data leaks by identifying vulnerabilities earlier.
The fact that DevSecOps helps to ensure compliance with laws and standards is another crucial feature of the practice. In many businesses, especially those that deal with sensitive or private data, including healthcare and banking, compliance is becoming more and more crucial. DevSecOps aids in ensuring that the software complies with requirements by incorporating compliance into the development process.
How does DevSecOps work?
What does DevSecOps look like in practice? DevSecOps is fundamentally about cooperation and communication between teams working on development, security, and operations. This implies that everyone bears some kind of responsibility for security, not just the security team. Instead of adding security features later, development teams collaborate with security and operations teams to incorporate security into the software from the start.
The automation of DevSecOps is a crucial element. Automation makes the development process more efficient, reduces errors, and ensures consistency. DevSecOps can aid in the quicker and more precise detection of vulnerabilities and threats by automating security testing and other security operations.
Continuous monitoring is a key component of DevSecOps. This means that maintaining security involves ongoing monitoring and improvement rather than being a one-time action. DevSecOps can assist in identifying and mitigating risks before they turn into significant concerns by continuously monitoring the program for security threats and vulnerabilities.
DevSecOps also depends on a culture that values security. As a result, security is more than just a collection of guidelines; it’s also a way of thinking and conducting business. Organizations may ensure that security is always a top priority and that everyone is aware of the significance of security in their work by developing a culture of security.
DevSecOps is a vital method of software development that places an emphasis on teamwork, automation, and constant monitoring. DevSecOps contributes to the creation of a security culture that guarantees the software is secure and complies with regulatory standards by integrating security into every phase of the software development lifecycle. Organizations that implement DevSecOps are well-positioned to produce secure and dependable software that satisfies the needs of their stakeholders and customers given the growing relevance of security in today’s society.
There are numerous online resources, like blogs, podcasts, and online courses, that you may use to learn more about DevSecOps. In the world of DevSecOps, there is something for everyone, whether you are a developer, security expert, or operations specialist.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson.
https://www.jamasoftware.com/media/2023/06/2023-6-8-devsecops-1.jpg5121024McKenzie Jonsson/media/jama-logo-primary.svgMcKenzie Jonsson2023-06-08 03:00:342024-01-18 00:02:33What is DevSecOps? A Guide to Building Secure Software
ARP4754A / ED-79A: Enhancing Safety in Aviation Development
Safety is always put first in the aviation sector. Strict adherence to rules and demanding standards helps to preserve this commitment to safety. This is where ARP4754A, a significant standard, comes into play. In this blog post, we will discuss the importance and function of ARP4754A (and its EASA equivalent ED-79A, henceforth ARP4754A) and how it impacts the design of civil aircraft and systems.
Understanding ARP4754
ARP4754A, commonly known as “Guidelines for Development of Civil Aircraft and Systems,” is an industry standard published by SAE International. Its goal is to create a structured procedure for the development and certification of aircraft and related equipment in order to guarantee adherence to safety rules. From initial concept to final certification, these rules are intended to serve as a reference for engineers, designers, and manufacturers. ARP4754A is recognized as an appropriate standard for aircraft system development and certification. The corresponding EASA Acceptable Means of Compliance AMC 25.1309 (included as a section of CS-25) does recognize ARP4754/ED–79 as well.
ARP4754A’s main goal is to increase aviation safety by encouraging a methodical and uniform approach to designing and developing aircraft and systems. It aims to reduce risks and dangers related to aircraft operations by resolving potential flaws and vulnerabilities. The standard’s goals consist of:
Safety Assessment: ARP4754A stresses performing in-depth safety evaluations to pinpoint dangers, weigh the risks, and put in place the right countermeasures. Revision A, specifically addresses functional safety and the design assurance process.
System Development: It offers recommendations for the development of aviation systems, including requirements management, verification and validation, and configuration management.
Considerations for Certification: ARP4754A guarantees that systems and aircraft adhere to legal criteria and certification procedures, supporting their secure integration into the aviation industry.
Development Lifecycle
The development lifecycle outlined by ARP4754A recommends adherence to established systems engineering principles and emphasizes the significance of iterative and incremental procedures, stakeholder collaboration, and requirement traceability throughout the lifecycle stages. The typical key processes covered by ARP4754A are well-defined:
Planning Process: This stage defines the means of producing an aircraft or system which will satisfy the aircraft/system requirements and provide the level of confidence which is consistent with airworthiness requirements.
Safety Assessment Process: Prescribes close interactions between the safety assessment process and system development process to capture safety requirements imposed on the design.
Architecture Planning and Development: The system architecture is established, including hardware, software, and interfaces
Requirements Process: Detailed system requirements are defined, considering functional, performance, security, and safety aspects.
Design Process: Detailed hardware and software item requirements are defined and allocated to system requirements.
Implementation Process: The system components are developed, integrated, and tested according to the defined design requirements.
Verification and Validation Process: This includes the activities necessary to demonstrate that the item requirements are complete, correct, and consistent with the system needs and architecture.
Integral Processes: ARP4754A describes additional processes that are applicable across all of the above processes. They are: Safety Assessment; Development Assurance Level Assignment; Requirements Capture; Requirements Validation; Configuration Management; Process Assurance; Certification & Regulatory Authority Coordination
The policy related to ARP4754A plays a crucial role in ensuring safety in the aviation industry. It employs a step-by-step approach to identify and address potential hazards and risks during the early stages of development. This policy prioritizes safety assessments, risk reduction, and thorough testing, ultimately minimizing the chances of any mishaps or incidents in practical scenarios.
Moreover, ARP4754A promotes a culture of collaboration where stakeholders can effectively share knowledge and communicate throughout the development process. This ensures that safety concerns are addressed, and all parties involved have a clear understanding of their respective roles and responsibilities. The result is a coordinated effort that leads to a successful outcome.
Conclusion
The aviation industry relies heavily on ARP4754A as a fundamental benchmark and acceptable means of compliance for the development of civil aircraft and systems. By adhering to a structured approach to development, it ensures aviation safety and minimizes possible risks. Its systematic lifecycle stages, emphasis on safety assessments, and compliance with certification requirements significantly contribute to the overall reliability and integrity of aviation products. Even as the aviation industry progresses, ARP4754A remains a critical reference point, promoting a safety-first mindset and reinforcing the industry’s dedication to passenger safety.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by Decoteau Wilkerson and Cary Bryczek.
https://www.jamasoftware.com/media/2023/05/2023-05-30-arp4754-ed79a-1-1.png5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2023-05-30 03:00:392024-01-18 00:08:27ARP4754A / ED-79A: Enhancing Safety in Aviation Development
Learn about the critical role of benefit-risk analysis in the development of safe and effective medical devices, including the use of ISO 14971, regulatory requirements, and optimizing for patient needs and healthcare costs.
The Importance of Benefit-Risk Analysis in Medical Device Development
Benefit-risk analysis is a crucial stage in the creation of medical devices. It entails evaluating the device’s possible benefits as well as drawbacks and deciding if the advantages outweigh the disadvantages. This examination aids in ensuring that medical devices are reliable, safe, and capable of being used by patients without harm.
The global standard for risk management of medical devices is ISO 14971. It offers a framework for recognizing, assessing, and managing hazards related to medical devices. Manufacturers must follow the standard and conduct a benefit-risk analysis as part of the risk management procedure. To ensure that the level of risk connected with a medical device are acceptable and that the benefits outweigh the risks, this analysis is crucial.
To start a benefit-risk analysis, it is important to first determine the device’s intended use(s). The device’s intended use should be defined in detail and contain information on the patient group it is meant for, the medical problem it is intended to support, and the clinical environment in which it will be used.
Finding the potential advantages of the device is the next step after defining its intended usage. Benefits could include better health outcomes, more comfortable patients, and lower healthcare expenses. These advantages should be measured and contrasted with any possible risks connected to using the technology.
A medical device’s dangers may include physical harm to the patient, adverse events, and device failure, according to the definition of harm within ISO 14971. The possibility and seriousness of each risk should be evaluated, and these risks should be identified and quantified.
Even after risks have been lowered as far as possible with risk controls, there may still be some unacceptable level of risks. This is why a benefit-risk analysis is so important in medical device development.
The following stage is to assess the benefit-risk balance after the potential advantages and risks have been determined. This entails weighing the device’s possible advantages and disadvantages to decide whether the benefits outweigh the risks.
If the benefits outweigh the risks, the device may be considered safe and effective for use in the intended patient population. However, if the risks outweigh the benefits, the device may not be considered safe or effective and may need to be redesigned or modified to reduce the risks, a medical device manufacturer might also make the decision not to launch the product to market.
Benefit-risk analysis must be optimized to guarantee the safety and efficacy of medical devices.
The benefit-risk analysis should be an ongoing process throughout the development and life cycle of the device. As new information becomes available, the analysis should be updated to ensure that the benefits still outweigh the risks, as prescribed in various regulations and standards such as 14971:2019, and EU MDR/IVDR.
Regulatory standards for medical devices should also be considered in the benefit-risk analysis. The Food and Drug Administration (FDA), which oversees medical device regulation in the US, requires manufacturers to prove their devices are safe and effective before they can be marketed or sold.
The FDA requires med device manufacturers to perform a benefit-risk analysis as part of the product development process. This analysis is used to determine whether the benefits of the device outweigh the risks and whether the device is safe and effective for use in the intended patient population.
Conducting a benefit-risk analysis is a critical step in the development of med devices. It involves identifying and evaluating potential benefits and risks and determining whether the benefits outweigh the risks. ISO 14971 provides a framework for performing a benefit-risk analysis as part of the risk management process.
Optimizing benefit-risk analysis is important for ensuring that medical devices are safe and effective, meet regulatory requirements, and are reimbursed by healthcare payers. A systematic approach that considers all relevant factors, including patient needs and preferences, and clinical outcomes.
Note: This article was drafted with the aid of AI. Additional content, edits for accuracy, and industry expertise by McKenzie Jonsson and Vincent Balgos.
https://www.jamasoftware.com/media/2023/05/2023-05-25-benefit-risk-med-1.jpg5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2023-05-25 03:00:412024-01-18 00:10:28The Importance of Benefit-Risk Analysis in Medical Device Development
Digital Transformation and the Importance of Requirements Management Within the DoD
Looking back on a technology career that started nearly 45 years ago gives me an opportunity to reflect on the evolution of technology trends. Most notably, for me, the usability and interfaces to that technology. Let me explain…
I started out as a young man in the Marines repairing and calibrating avionics equipment, and general test instrumentation. After boot camp (basic training) the Marines saw fit to send me to a half dozen electronic schools to learn my craft. Every piece of equipment I touched had a physical reference, and user’s manual, but for the most part, if you knew what function a piece of gear was supposed to provide, you probably didn’t need a manual very often. For example, if I knew how to use a Tektronix oscilloscope, I probably didn’t need any instruction on how to use an o-scope from Hewlett Packard or Phillips. Just about everything I needed to know was obvious and accessible on the front panel (the user interface).
Over the next 15 years that paradigm stayed relatively consistent. I would see different types of equipment, work on different ‘things,’ but it was rare that training or anything other than an occasional manual was needed to be productive. Physical interfaces tended to ‘tell all’ about what I could do, or what I needed to do with a piece of electronic equipment.
It was about this time that I made a mid-career switch. It had become obvious (to me, at least) that software was going to be in EVERYTHING. Consequently, I went back to school for a Computer Science (CS) degree to help in gaining access to that world. With CS degree in hand, I took a position writing test software on a classified program for an aerospace giant. It was interesting at one level when I could see the end results of my efforts, but it could be laborious at times. I shared a large cubicle with two teammates, and we were heads down grinding on code for most of the day. I know some find this immensely rewarding, but I was not one of them.
Whilst I knew this wasn’t my calling in life, the introduction to a software development organization gave me exposure to tools supporting the software development lifecycle (SDLC). Disciplines like requirements management, configuration & change management, and architectural modeling. Plus, the software development process itself: Waterfall, Spiral, Iterative, Agile to name a few. The code may be the ultimate deliverable, but there are a lot of moving parts to get the code out the door. Of course, not every team believed in all of those ‘other’ disciplines: I had one teammate that had a sign over his desk that read, “Documentation is for wimps!” I also remember a cartoon at that time that read something like (manager speaking to developers): “You start writing the code while I go upstairs and see if they have any requirements.”
I’ve spent the bulk of the past 20 years of my work life supporting and working with Federal DoD programs – the large System Integrators, and direct with programs at military installations around the country. In that time, I’ve seen the transformation of segments of programs/projects being focused on a singular discipline (e.g., requirements, code, test, etc.) to the point where they are taking the big picture view; that systems and software development is really a team sport. Instead of each discipline developing their own assets/artifacts and ‘throwing them over the wall’ the work is now being attacked in a cohesive and coordinated fashion. Essentially, a digital transformation where we’ve gone from just ensuring that each discipline has tooling to support their own work, to the point where each segment of the development lifecycle prioritizes the ability to link and trace to the upstream and downstream activities.
In the earliest of days of tracing assets across all disciplines the tool vendor who could supply an environment that supported all facets of development, and link those assets together had an advantage. However, over time, the end user became more sophisticated. They did not want to lock themselves into a single vendor with tools that were ‘good enough,’ they wanted a best-of-breed product for each of those disciplines.
I think that’s the primary reason that I’m excited to be part of the team at Jama Software®. I spent 16+ years being that single vendor with tools that were integrated and were ‘good enough.’ Now, I have a product that arguably is the centerpiece of the most important of disciplines, requirements management. For without accurate requirements, on time, on budget, and meeting the needs of the end user (or warfighter) is a difficult undertaking.
At Jama Software®, we support Live Traceability™ – the ability to link and trace outside our domain of requirements, to the other best-of-breed tools that support things like coding, change management, architectural modeling, testing, etc. Jama Connect® does not lock you into a single vendor but gives you the ability to continue to use the products you currently have in your arsenal. Live Traceability gives your team the ability to see the most up to date and complete up and downstream information for any requirement, no matter what state of development it is in or how many siloed tools and teams it spans.
Being a part of the Jama Connect team has allowed me to work with the most intuitive of all tools in my career. When I say intuitive, I mean I didn’t need any training to get up and running to be productive. Additionally, Jama Connect is a cloud-based product (self-hosted is also available), so no need to worry about getting your IT team engaged. If a Jama Connect project is properly set up, it should expose the bulk of the functions needed for a person working in the requirements discipline. Notice I did not say ‘requirements manager.’ Systems/Software development is a team sport, and more roles than just a requirements manager/SME will need access to the requirements. It is rather easy for a non-requirements person to access the tool, explore its functions, and be productive with limited or no training.
I continue to support Aerospace & Defense programs in my role at Jama Software. In addition to Jama Software offering a great requirements management tool, they are industry experts, and provide expert thought leadership and best practice guidance to their clients. This level of knowledge is a key distinguishing factor when searching for a requirements management tool. I am very happy to be part of this extremely energetic, client-focused company and truly looking forward to this next phase of my career.
https://www.jamasoftware.com/media/2023/05/2023-05-18-digital-transfomation-dod-1.jpg5121024Gary Hayes/media/jama-logo-primary.svgGary Hayes2023-05-18 03:00:252024-01-18 00:12:40Digital Transformation and the Importance of Requirements Management Within the DoD
A Nod To MOSA: Deeper Documenting of Architectures May Have Prevented Proposal Loss
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.
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.
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.
https://www.jamasoftware.com/media/2023/05/2023-05-03-mosa-2-1.jpg5121024Cary Bryczek/media/jama-logo-primary.svgCary Bryczek2023-05-03 03:00:052024-01-18 00:23:44A Nod To MOSA: Deeper Documenting of Architectures May Have Prevented Proposal Loss
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.
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:
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.
https://www.jamasoftware.com/media/2023/04/NEW-2022-11-17-trial-master-file-1.png5121024Vincent Balgos/media/jama-logo-primary.svgVincent Balgos2023-04-27 03:00:052024-01-18 00:25:08What is a Trial Master File in the Medical Device Industry?
