Tag Archive for: systems engineering

In this blog, we recap our webinar, “Unlocking Success: The Transformative Benefits of Variant Management through Product Line Engineering” – Click HERE to watch it in its entirety.

Unlocking Success: The Transformative Benefits of Variant Management Through Product Line Engineering

Embark on a journey of innovation and efficiency with this webinar on the benefits of variant management through Product Line Engineering (PLE), as we explore how PLE serves as a catalyst for organizational success.

In this insightful session, our industry experts will guide participants through the myriad advantages that PLE offers in the realm of product development, including:

    • How PLE accelerates time-to-market and significantly reduces costs by promoting systematic reuse of engineering assets across a product portfolio.
    • The strategic impact of PLE on managing product variability, enabling organizations to swiftly adapt to changing market demands without compromising quality.
    • A way to gain a competitive edge: Learn how PLE can be implemented in Jama Connect® to enhance collaboration among cross-functional teams and create adaptable architectures

Below is an abbreviated transcript of our webinar.

Matt Mickle: Today I will spend some time introducing the topic of product line engineering and some of the benefits, as well as challenges that come along with it, especially pertaining to the work that you need to do in Jama Connect. I’ll then hand it off to Geoff, who will walk you through a practical way to implement product line engineering into the way that you work within Jama Connect now. We’ll then sum up and take away any questions from the audience. So without any further ado, let’s jump right into it.

What is product line engineering? Well, there’s multiple definitions floating around for product line engineering, but for the purpose of this webinar, we’re going to stick to something that makes sense from our perspective, which is a focus on engineering for a family of products with similar features, components or modules, as a single product line in order to leverage the commonality and variability, minimize the duplication of effort, and maximize reusability.

There are lots of examples of what a product line could be. It could be a series of vehicles, such as what you see here with the J Series, where you have different models that are part of a single product line. It could be military vehicles developed for different roles. It could be versions of software that are built for different types of consumers, like your light user or your expert user. It could be a line of appliances with different sizes or capabilities, like an oven or a dishwasher. It could be a line of laptops with different sizes, different amounts of memory, and different amounts of CPU. Or for a semiconductor, it could be configurations of IP for a chip family. So lots of different ways that you could have a product line, and with many of those ways you need to think about product line engineering.

RELATED: Jama Connect® vs. IBM® DOORS®: Reuse and Variant Management

Mickle: What are variants and how do you manage those variants? Along the same pathway, we will refer to variants as basically anything that would vary from product to product within a product line. And that could include some of the examples below, like different features, premium services, levels of performance, and different components that you might have, kind of like what you see on this ad for the J Series turbo. And when it comes to variant management, we’ll simply refer to this as the process or the technique that helps us manage and organize the variance. And this could be through one or multiple of these different modes that you see below, or it could be something that’s not listed there.

Okay, so what are some of the benefits that we get from product line engineering and from variant management? One is product line engineering, which enables organizations to create a product line architecture that allows for a systematic reuse of components. This can be components, modules, assets, and those are across different products within a product line. This promotes efficiency by reducing redundancy in the need to recreate similar functionalities for every product.

Another way is by reusing existing components and assets, organizations can significantly reduce their development cost. Product line engineering allows for economies of scale, as the investment in creating a core set of assets can be spread across multiple products, leading to cost savings in the long run. With product line engineering organizations can also streamline the development process by leveraging those existing components and architectures. This means faster time-to-market for new products since development efforts are focused on creating unique features, rather than rebuilding common functionalities.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Mickle: It also helps ensure consistency in the products across your product line. If you reuse well-tested and validated components, the likelihood of introducing defects or inconsistencies is reduced, and that leads to higher overall product quality. As the market demands change or new technologies emerge, product line engineering provides a framework that allows organizations to adapt and evolve their product line more easily. This enables the addition of new features or the modification of existing ones without starting the development right from scratch.

Product line engineer also supports efficient configuration management, therefore allowing organizations to define and manage variations and products through configuration, rather than by creating separated versions or desynchronized copies of content. It simplifies a task of handling different customer requirements or market-specific adaptations.

It also makes the maintenance and updates more manageable. Changes or bug fixes can be applied to common components, and the updates can then be propagated to all the products in the line, ensuring that each product benefits from the improvements without having to undergo individual modifications. It also helps with the mitigation of risks associated with product development by relying on well-established improving components. Since these components have been used and tested across multiple products, the likelihood of critical issues arising is reduced.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Unlocking Success: The Transformative Benefits of Variant Management through Product Line Engineering

Blog image for MIL-STD-810 showing engineer holding a clipboard.

MIL-STD-810: Ensuring Quality and Reliability in Challenging Defense Environments

From the desert to swamps to the frozen tundra, the United States Department of Defense (DoD) created the Military Standard 810 (MIL-STD-810) to enforce manufacturers deliver a product that will not fail in operational environments. This compliance regulation outlines environmental engineering considerations for testing equipment’s durability, performance, and quality in challenging and harsh environments. The blog will explain the significance of MIL-STD-810, its purpose, and how it impacts industries and consumers worldwide

Understanding MIL-STD-810

MIL-STD-810, widely used by commercial, non-military entities as well, prescribes a series of tests and procedures that have been created to measure the durability of equipment and its ability to survive in tough conditions.

Initially published in 1962, the standard has been regularly updated to keep up with technological developments and the varying environmental conditions. MIL-STD-810 thus serves as a useful tool for manufacturers, guaranteeing that their products can withstand the toughest circumstances.

The Purpose of MIL-STD-810

Defense contractors and manufacturers are required to meet the requirements outlined in this standard to sell their equipment to the U.S. military. MIL-STD-810 is used to ensure operability of equipment in conditions it may come across during its service life. The standard provides a broad selection of environmental factors and tests to go with them, allowing companies to find any weak points and make the necessary changes. By following this standard, it will help to improve the reliability and robustness of their product, resulting in successful harsh environment operation and a longer life in the field.

RELATED: Jama Connect® Airborne Systems Solution Overview

Key Environmental Factors Tested under MIL-STD-810

  • Temperature: Equipment is exposed to a broad range of temperatures, from frigid cold to blazing hot, to make sure its performance and security are up to the task in different climates.
  • Humidity: Checking the humidity level helps to guard the device from harm and ensure it functions properly in areas with high levels of moisture.
  • Shock: Devices are tested by subjecting them to mechanical shocks, such as drops and vibrations, to replicate real-world conditions and to evaluate their structural soundness and operation.
  • Vibration: The MIL-STD-810 outlines a variety of different vibration tests to simulate any transportation or operational movements that may affect the performance or parts of a device.
  • Sand and Dust: The capability of the equipment to resist being exposed to tiny particles such as sand and dust that are commonly seen in desert and arid areas is appraised.
  • Altitude: Checking the equipment’s operation at various altitudes determines its capacity in different air pressures, guaranteeing its dependability in high-altitude zones.
  • Solar Radiation: Evaluating the equipment’s response to solar radiation helps manufacturers understand its performance in outdoor environments with direct sunlight exposure.
  • Rain: Devices are tested to withstand exposure to rain and water, preventing water intrusion and potential short circuits.

Impact on Industries

    • Military and Defense: MIL-STD-810 is mandatory for military and defense contractors. Ensuring equipment works well in harsh conditions is vital for military operations. Compliance reduces the risk of equipment failure in critical situations.
    • Aerospace and Aviation: The aerospace industry uses MIL-STD-810 to make equipment for aircraft and space missions. The standard makes sure that equipment can handle extremes in flight and space conditions.
    • Consumer Electronics: MIL-STD-810, originally intended for military use, has been embraced by consumer electronics producers. This has resulted in the production of rugged smartphones, tablets, and laptops for those with a fast-paced lifestyle or who do their work in demanding settings.
    • Industrial Equipment: Industrial equipment and machinery often must endure difficult conditions, such as those found at construction sites and mining operations. By following MIL-STD-810 guidelines, manufacturers are able to produce sturdy and resilient machinery that can endure these types of settings, reducing the need for maintenance and repairs.

RELATED: Requirements Traceability Diagnostic

Conclusion

The MIL-STD-810 is of major importance in the assurance of the quality and dependability of equipment across myriads of industries. By undergoing multiple environmental examinations, companies can notice and tackle possible problems before their equipment is delivered to customers and stakeholders. This guideline has not only ensured reliability of military devices but has also played a role in the construction and production of commercial electronics and industrial machines.

In a world where technology is more and more ubiquitous, MIL-STD-810 remains a fundamental point of reference in managing the difficulties of hostile and unpredictable environmental conditions. Its impact will remain, prompting manufacturers to construct reliable and rugged devices that meet the requirements of the DoD and commercial customers across the world.

How Can Jama Connect® Help?

Jama Connect®‘s digital engineering strategy is essential for any organization seeking to increase efficiency and reliability. It serves as an essential bridge between teams, optimizing design and engineering processes. With its comprehensive system view and dependable source of information, it is an invaluable asset for achieving success.

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


NASA Systems Engineering Handbook Rev2

Unveiling the NASA Systems Engineering Handbook Rev2: A Comprehensive Guide for Space Exploration

NASA, the National Aeronautics and Space Administration, has been at the international forefront of space exploration for decades, pushing the boundaries of human knowledge and expanding our understanding of the universe. Behind every successful NASA mission lies a robust framework of engineering practices and principles, which are meticulously documented and compiled in the NASA Systems Engineering Handbook Rev2. In this blog post, we will delve into the key aspects of this handbook, exploring its purpose, contents, and the diverse range of professionals who rely on it.

Understanding the NASA Systems Engineering Handbook Rev2

The NASA Systems Engineering Handbook Rev2, also known as NASA/SP-2007-6105 Rev2, is a comprehensive guide that provides detailed insights into the principles, practices, and processes of systems engineering as applied to space missions. It serves as a valuable resource for engineers, scientists, project managers, and other professionals involved in the planning, development, and execution of NASA missions.

In comparison to NASA Systems Engineering Handbook Rev1, which was published in 1995, Rev2 is a modernized version that aligns with current practices, incorporates lessons learned from recent NASA missions, and integrates more current technologies and tools to enhance system development and management.

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

Purpose and Objectives

The primary objective of the handbook is to promote effective systems engineering practices within NASA and its associated programs. It outlines a standardized approach to managing complex projects and ensures that all aspects of engineering are considered throughout the lifecycle of a mission. By adhering to the guidelines presented in the handbook, NASA aims to enhance mission success rates, mitigate risks, and optimize resource utilization.

Contents and Key Topics

The NASA Systems Engineering Handbook Rev2 covers a wide range of topics, providing a holistic view of the systems engineering discipline. Some of the key areas addressed in the handbook include:

  • Introduction to Systems Engineering: This section provides an overview of systems engineering principles, concepts, and the overall engineering process. It lays the foundation for understanding the subsequent chapters and their relevance to space missions.
  • Systems Engineering Processes: Here, the handbook outlines the various processes involved in systems engineering, such as requirements development, design, verification, validation, and risk management. It emphasizes the importance of a structured and iterative approach to achieve mission objectives.
  • Systems Engineering Management: This chapter focuses on the management aspects of systems engineering, including organization structures, roles and responsibilities, and project planning and control. It provides guidance on effectively managing interdisciplinary teams and fostering collaboration.
  • Systems Engineering Tools and Techniques: The handbook explores the tools and techniques commonly employed in systems engineering. It covers areas like modeling and simulation, trade studies, configuration management, and system integration and testing. These tools facilitate informed decision-making and ensure the successful integration of complex systems.
  • Systems Engineering and NASA Programs: This section discusses the application of systems engineering within various NASA programs, highlighting the specific challenges and considerations associated with each program. It encompasses areas such as human spaceflight, robotic exploration, Earth science missions, and astrophysics.

RELATED: Aerospace & Defense PLM Action Group Digital Thread Collaborative Research Report

Users of the NASA Systems Engineering Handbook Rev2

The NASA Systems Engineering Handbook Rev2 is an invaluable resource for a wide range of organizations involved in space exploration system development. The following are some key users of this handbook:

  • Engineers and Scientists: Systems engineers, aerospace engineers, and scientists working on NASA projects rely on the handbook for guidance on best practices, processes, and techniques. It provides them with a standardized approach to system development, ensuring consistency across missions.
  • Project Managers: The handbook offers project managers a comprehensive understanding of systems engineering principles. It assists them in establishing project plans, managing risks, and coordinating activities across multidisciplinary teams.
  • Academia and Research Institutions: The NASA Systems Engineering Handbook Rev2 is widely used as a reference in academic and research institutions. It serves as a guide for students, researchers, and professors involved in space-related studies and projects.
  • Industry Professionals: Engineers and professionals working in the aerospace industry often refer to the handbook as a benchmark for best practices. It helps them align their methodologies with NASA’s standards, enabling seamless collaboration with the agency on joint projects.

Conclusion

The NASA Systems Engineering Handbook Rev2 stands as a testament to NASA’s commitment to excellence in space exploration. By encapsulating the best practices and experiences from numerous successful missions, this updated comprehensive guide empowers engineers, scientists, project managers, and other professionals involved in NASA programs. With its emphasis on a structured approach to system development, risk management, and interdisciplinary collaboration, the handbook plays a pivotal role in ensuring the success and safety of future space missions.

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


Defense

Streamlining Defense Contract Bid Document Deliverables with Jama Connect®

In the defense sector, whether it is a large prime, a subcontractor, or one of the thousands of other organizations under the defense umbrella, winning a contract bid for the United States Government comes with as astronomical amount of document deliverables that can be daunting and cumbersome. These documents are listed from the get-go in the Contract Data Requirements List (CDRL) which links directly to the Statement of Work (SOW). When designing and building these complex programs, as part of the CDRL, the contractor delivers countless Data Item Descriptions (DIDs).

These DIDs are formatted with very particular structures and arrangements as defined by MIL-HDBK-245 so that each unique deliverable defines the necessary data. Examples of these documents are Interface Design Description (IDD), System/Subsystem Design Description (SSDD), and Operation Concept Description (OCD) just to name a few of the variations. Below you can see a list of DIDs that are offered with Jama Connect®. The Software Requirements Specification (SRS) DID contains the formatted document below in the explorer tree so the export is pre-built and only the pertinent information can be filled in.

Figure 1: Jama Connect DID Template Library

Prior to entering the world of Jama Connect, my experience at the largest government contractor as a Systems Engineer exposed me to countless hours of document writing, specifically Interface Design Descriptions (IDD’s). The team had to create 80 documents from scratch for two different programs. Mind you, these 80 documents were solely for the navigation data that our systems sent to the rest of the ship. These documents are just a small segment of all the other similar documents that numerous teams worked on. These IDD’s were kept on the Local Area Network (LAN) where revision management was adding a most recently edited date to the end of the file name and completion was tracked in a excel workbook. Upon completing a document, the team would sit in room together to review a few IDD’s, try to remember if any system changes that were made, cross reference Cable Block Diagrams and Cable Run Sheets to see if all connector types and port numbers were correct, and struggle to make sure all interfaces for the connected systems were captured.

RELATED: Digital Engineering Between Government and Contractors

There was no relationship capability, no way to ensure up to date references, and minimal visibility into change incorporation. This led to unnecessary hours spent reviewing these items ultimately leading to late delivery of documents and the possibility of incorrect or out of date documents which the customer was not appreciative of. With the navigation system being the core of all ship operability, the risk of incorrect documentation had the potential to lead to countless issues on ship in an environment where the stakes are already so high. The premise of being able use Jama Connect to build these DID’s with the information already created in the software that establishes traceability and ease of review in the review center is lightyears easier and faster than the process we had in place.

Now that the stage is set for the effort that goes into delivering all the CDRL items, by utilizing Jama Connect, customers no longer must burn thousands of hours meticulously revisioning items in Word documents. The DID structure can be built into a Jama Connect project so that the DID can be broken down into individual components to be versioned on. Utilization of the REUSE capability allows for requirements and other text items from the project to be simply implemented in the DID structure so that the content is the same and the exported deliverable meets the criteria. Alongside the simplicity of creating DID’s within Jama Connect, the overall authoring process is reduced tenfold since numerous users can work in conjunction on their own elements of the DID, the out of the box templates offered give users the ability to immediate start creating the content, and overall deliverable time is cut down.

RELATED: How Jama Connect® Helps Program Managers with DOD 5000 Adaptive Acquisition Framework

Conclusion

The daunting task of delivering countless documents to the government is much less alarming when streamlined with the use of Jama Connect. With Jama Software’s DID’s Library, customers are able to dive into their deliverable creation while simultaneously working in an environment that provides perfect versioning and change management for the items that make up the DID. The ability to deliver documentation to the customer in a faster, more concise manner yields companies the ability to stop wasting time of writing documents from scratch and to instead complete other tasks leading to overall acceleration of a program.


digital engineering

Digital Engineering Between Government and Contractors

How does a digital thread work when tool ecosystems are disconnected from each other? For the defense contracting world, THIS is the elephant in the room. The DoD (Department of Defense) wants its Digital Engineering (DE) vision to become a reality and they do realize it cannot happen overnight, so how is this being addressed today?

The short answer is that the DoD wants their contractors to set up their own DE ecosystems and then exchange deliverables. This is no different than what they have done for the past 50 years but the types of deliverables are changing. Namely, they want DE content to be delivered as models which means SysML, UAF (an enterprise architecture format), Computer Aided Design (CAD) I– if the government purchased the technical data for this during contracting – models. The DOD still requires deliverables in Word/PDF/Excel/MS Project for various project management deliverables and engineering analysis that is only representable in textural form as well.

“Within the new Digital Engineering Ecosystem, there are three possible scenarios for information access between customer and contractor. The scenarios are: 1. Provide access to controlled baselines in contractor environment. This is considered a low IP (Intellectual Property) and data rights loss risk option two. Provide access to controlled baselines in the contractor environment and provide selected models and data in accordance with contract data requirements. This is considered a medium IP and data rights loss risk option 3. Provide all required baseline models and data in accordance with contract data requirements. This is considered a medium-high IP and data rights loss risk option.” – (AIA Aerospace whitepaper)

Nightly Check-in Technique:

PLM tools are deemed the center of the ecosystem since these already have the digital twin information (hardware CAD, configuration management, and product management backbone) in place. Nightly check-ins of files (SysML model, CAD, requirements, Ansys, etc.) are thought to be timely enough to keep things in sync. With this model, both the government and contractors would utilize a shared or their own PLM systems.

SAIC ReadyOne – a ready-made DE ecosystem of tools that can be purchased and installed in one click. It is managed on AWS GovCloud and is available up to CUI level four today. It is meant to answer the call for an easy to deploy, cost effective, and powerful integrated environment that delivers Digital Transformation – SAIC created Ready 1. ReadyOne is comprised of two main components

  • The infrastructure which includes the servers, application stacks, and build automation
  • And the Digital thread platform with a custom data model – which you can think of as the plumbing that defines the available connections between the various data artifacts – like system models, parts, and simulations – within the ecosystem

ReadyOne is Built on a model based, low code, platform supporting openness, flexibility, and customization. OOTB applications allow domain specific content to be mapped to Items and artifacts as well as customization – ensuring uniqueness of process, instead of forcing synthetic commonality.

Developers use familiar domain specific applications for System Modeling, CAD, and simulation to author content. Domain tools utilize pre-configured connectors with business rules to ensure all data is connected and the single source of truth remains persistent. Enterprise configuration management is a foundational component ensuring each domain is utilizing the proper data and relationships to remove opportunity for errors.

Digital Thread

SAIC Proprietary

INCOSE Digital Engineering Information Exchange Working Group (DEIX-WG)

Group Goal = “The DEIX WG primary goal is to establish a finite set of digital artifacts that acquiring organizations and their global supply chains should use to request an exchange with each other as well as internally between teams/organizational elements.”

Product Descriptions:

  • DEIXPedia: Micropedia of digital engineering topics to explain relevant DEIX topics. STATUS = In place and updating
  • Primer: A Narrative that describes the concepts and interrelationships between digital artifacts, enabling systems and exchange transactions. STATUS = DRAFT
  • Digital Engineering Information Exchange Mode (DEIXM): A prescriptive system model for exchanging digital artifacts in an engineering ecosystem. STATUS = DRAFT
  • DEIX Standards Framework (DEIX-SF): A framework for official standards related to MBSE (Model Based Systems Engineering) Information Exchanges. STATUS = DRAFT

Digital Thread Chart

RELATED: Traceability Score™ – An Empirical Way to Reduce the Risk of Late Requirements

Defense Systems Integrator – Digital Engineering Use Case and Lessons Learned

At the NDIA 25th Annual Systems and Mission Engineering Conference one large defense contractor presented their working tool ecosystem and explained their use case and lessons learned.

Use Case:

  • Provide system stakeholders with visibility into the system
  • For Example:
    • Determine impact of a Change to the System (e.g., requirement, model, part.)
    • Determine impact of Simulation to the System (e.g., validate or invalidate a requirement.)
  • To do this, I will need a digital engineering ecosystem that:
    • Enables the integration of repositories, i.e., requirements database, SysML models, PLM system.
    • Provides a framework for creating digital threads across data repositories.
    • Provides a mechanism for querying / visualizing digital threads.
    • Provides a way to compare/sync data repositories.
    • Can perform model/data transformations, e.g., DNG requirement → SysML requirement.

Dassault Cameo Systems Modeler is being used as the main user interface to coordinate with other models in other engineering domains, e.g., Creo, DNG etc.

Intercax’s Syndeia Cloud and Cameo plugin is good at connecting artifacts across different engineering repositories (DNG, Teamcenter, etc.) This group felt that Syndeia was the easiest to use and offered the most connections to their various tools. (Cameo, Teamwork Cloud, DNG, Teamcenter, Creo, Jira, GitHub, MySQL, Volta, Matlab/Simulink, Excel) They felt that in most cases Reference Connections were ideal and that reporting and analysis of the digital thread in the Syndeia Cloud webapp was more robust than anything other tool in the marketplace. They felt that Syndeia Cloud’s export of digital threads relationships into Excel to give to government customers was satisfactory.

Their Lessons Learned:

  • Define the Process for creating “reference connections”:
    • Who creates and manages the links.
    • Directionality of the link are consistent. Note: SysML element should always be identified as the source of the link.
  • Identify what types of links (digital threads) you want to create, for example:
    • Create reference connections from DNG functional requirement(s) to its SysML <<functional>> block to show a <<satisfy>> relationship.
    • Create reference connections from a Teamcenter part/item/assembly to a <<physical>> SysML block to show a <<satisfy>> relationship.
  • Establish operational and QA environments for Syndeia:
    • For testing out new patches and upgrades.
    • QA environment for training/experimentation.
  • Use caution of using “Local Repositories” (because they are local!)
  • Configuration manage your data repositories:
    • Teamwork Cloud for Cameo.
    • Global Configuration Management (GCM) for DNG.

RELATED: Write Better Requirements with Jama Connect Advisor™

Model-Based Acquisition (MBAcq)

An increasing number of RFPs are not only requiring MBSE but RFPs themselves are now starting to be created as SysML models and responses are expected to be returned in a SysML model file. Yes, there are SysML tool vendors (PTC, Spec Innovations) and even contractors (L3Harris) asking the DoD to drop its language so that the file format is compatible with Cameo. These vendors are trying to ensure they can export and import tool-agnostic SysML that is interoperable with each other.

The challenge to both the supplier and provider is the lack of standardization in the approach, resulting in a learning curve for every proposal as well as response. To address this concern, the OMG UAF MBAcq Working Group was formed to survey the current landscape with participation from government, industry, FFRDC’s, tool vendors, NDIA, and OMG standards org. The goal is to come up with process guidance and a SE (Systems Engineering) and architecture guidance.

Planned Deliverables:

  • ARM template and guidance (how to specify model-based DIDs, CDRLs.)
  • GRM template and guidance (includes guidance for how NOT to over-specify a system.)
  • Sample model (as part of UAF sample model.)
  • UAF Process Guide for Acquisition will:
    • Define the CONOPS for how a program office will use all the models they will receive over the lifetime or a system.
    • Demonstrate how to make models available for reuse for other/new systems.
    • Provide portfolio management for the models/programs.
    • Provide process and guidance that describes how to integrate MBSE approaches into pre-acquisition (before request for proposal release), request for proposal, contract award, and contract execution steps.
  • Impact to existing policy with recommendations for change.
  • Descriptions of what Sections K, L, and M could look like for model delivery.
  • Taxonomies with precise definitions for concepts and terms.
MBSE Digital Thread Chart

NDIA 2021 Systems & Mission Engineering Conference

Digital Engineering Tool Suites

According to SBE Vision, digital engineering tools are a mixed bag of silos:

  • Not all tools lend themselves to remote linking data at rest.
  • Some tools don’t have a web server.
  • Many detail design tools require a “local” model data as a basis for initial processing.
  • Sometimes a transformative capability of some kind is needed.
  • Certain use cases require a mashup of three or more systems.

Two Worlds Apart

SBE Vision is also developing techniques for both OLSC and synced data approaches. Complications can arise from linking vs syncing, such as company product, use case dependent, and can change over time.

OSCLS – Linked Data:
  • Remote linking of data
  • Peer-to-peer
  • Human oriented
  • Benefits:
    • Data stays at rest
    • Clean paradigm
    • Standards
  • Challenges:
    • Semantics (relational)
    • Configuration management
    • Change management
    • Consistency of standards implementation
Synchronization
  • Creating (temporary) copies of data
  • Hub-and-spoke
  • Human & machine Oriented
  • Benefits:
    • Enables many use cases
    • Simple, easy to use
    • Rich transformation when needed
  • Challenges:
    • Semantics (relational & transformative)
    • Configuration management
    • Change management
    • Managing correlation/sync state

Conclusion

Jama Connect enables real-time team collaboration through traceability and digital threads. To learn more about achieving Live Traceability™ on your projects, please reach out for a consultation.


IEC 15288

A comprehensive look at ISO/IEC/IEEE 15288 goals, standards, and tools to achieve compliance.

Product development is evolving quickly; over the past few years, it’s become increasingly complex. A study of nearly 300 design and engineering professionals found that 92% of respondents say they’re experiencing at least one form of increased complexity. Moreover, 76% say they’re experiencing at least three.

A set of standards, such as those found in ISO/IEC/IEEE 15288:2015, can help manage increased complexities using established frameworks. But if you aren’t familiar with the standards, you might have many questions such as: What is ISO/IEC/IEEE 15288:2015? What organizations use it? And how can it help with product development?

We’ve created a guide to help answer these questions so you can determine whether using this standard is right for your organization and explore other tools that can help.

RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond

Why was ISO/IEC/IEEE 15288:2015 developed?

Building a new system is a large undertaking that involves a variety of moving parts and components. The success of any project, of course, relies on those parts working in synergy and solving for any potential disconnects. That’s why having a common set of practices can help. ISO/IEC/IEEE 15288:2015 was designed to create a standard reference of activities to be executed within a specific system engineering process. The standards are designed for those in systems engineering leadership, such as:

  1. Systems Architects
  2. Systems Developers
  3. Project Managers
  4. Computer Scientists

The standards are commonly used to guide internal work on systems development but can also be used as an external reference. For example, if you work with a partner, you might use ISO/IEC/IEEE 15288:2015 to help create agreements about how work is completed.

Building a New System is Growing More Complex

A recent study of almost 300 design and engineer professionals found that not only are engineering systems getting more complex, but many organizations aren’t equipped with the right tools to manage the intricacies of complex system development.

  • 92% of respondents reported experiencing at least one form of increased complexity.
  • 76% report dealing with three or more increased measures of complexity.
  • 25% report their products are becoming more complex in five or more ways.

How is ISO/IEC/IEEE 15288:2015 used?

During product and system development, you’re working to solve a specific customer challenge. Using ISO/IEC/IEEE 15288:2015 helps you accomplish this goal by providing a framework for your processes. But how exactly are standards typically used? Here are a few examples.

  • Used by an organization. An organization might use ISO/IEC/IEEE 15288:2015 to create an environment of desired processes. An infrastructure or method, procedures, technologies (and more) typically support these processes.
  • Used by the project. You might decide to use what is found in ISO/IEC/IEEE 15288:2015 as internal standards to support the deployment of an existing environment or offer a new system or service. In addition, standards are used to judge the performance of a project in a specific environment.
  • Supports partner agreements. Agreements are the foundation of any successful relationship, including those with suppliers or other external parties. You might partner with a supplier, for example, to select relevant processes and activities within the standards and create agreements based on those elements.
  • Used to evaluate processes. ISO/IEC/IEEE 15288:2015 can serve as a process reference model to determine whether your existing processes support a specific goal around process improvements.

As you can see, you have flexibility when using standards. You can implement all frameworks or just a few of them. ISO/IEC/IEEE 15288:2015 can serve as a starting point, selecting what fits best for your project, processes or organization to guide your decisions.

To learn more about what’s included in each of the six parts of ISEO/IEC/IEEE 15288 and how Jama Software can help, download our Comprehensive Guide here. 

GAMP5

In this blog, we define GAMP®5, the framework for a risk-based approach, with an introduction and conclusion provided by Jakob Khazanovich, Medical Device Solutions Consultant at Jama Software®.

This blog contains details sourced from the International Society for Pharmaceutical Engineering.

What is GAMP®5 and How Does Its Guidance Help Regulated Companies Using Computerized Systems?

When medical product companies decide to implement a new software tool, an important question arises regarding the level of computer system validation required to ensure the latest software complies with regulatory requirements and industry standards.

One major guidance document companies should reference to answer this question is Good Automated Manufacturing Practice (GAMP®5): A Risk-Based Approach to Compliant GxP Computerized Systems.

RELATED: Convergent Dental Selects Jama Connect® For Its Live Requirements Traceability

GAMP

What is GAMP®?

GAMP® is a set of guidelines for producing quality equipment using the concept of prospective validation following a life cycle model. It was specifically designed by the International Society for Pharmaceutical Engineering (ISPE) to aid suppliers and users in the pharmaceutical industry.

GAMP stresses the use of critical thinking and risk-based assessments to justify the testing approach of a software tool. Its guidelines are widely supported by regulatory agencies and are used globally by regulated companies using computerized systems for compliance and validation.

What is GAMP®5?

GAMP®5 refers to the ISPE’s guidance document, “GAMP®5: A Risk-Based Approach to Compliant GxP Computerized Systems”. This GAMP®5 guide offers a framework for a risk-based approach to computer system validation in which a system is evaluated and assigned to a predefined category based on its intended use and complexity.

Though the steps in this guidance document are not mandatory, the framework provides a comprehensive approach to computer system validation that is generally accepted within the industry.

Additionally, its approach falls in line with the European EMA and US FDA regulations governing computer system validation, Annex 11 and 21 CFR Part 11.

Based on input from experienced IT, automation, and software practitioners, one of the reasons GAMP® guidance has always been successful is because it reflects the good practices for modern IT and software engineering teams.

RELATED: Jama Connect® and FDA 21 CFR Part 11

GAMP®5 Second Edition

Released in July 2022, GAMP® 5 Second Edition prioritizes patient safety and product quality over compliance and encourages the application of critical thinking. The overall GAMP® 5 framework, key concepts, and ICH Q9 aligned Quality Risk Management approach remain unchanged from the First Edition.

GAMP® 5 Second Edition supports standards set for forth by the FDA CDER (Center for Drug Evaluation and Research). Those standards call for “maximally efficient, agile, flexible manufacturing sector that reliably produces high-quality drug products without extensive regulatory oversight, where the vision requires moving beyond simply meeting minimum CGMP standards and towards robust quality management systems.”

This updated version of the guideline aims to help teams meet compliance expectations by offering best practices for IT teams, recommendations for optimal Quality Risk Management approaches, and ways to excel in software engineering, all while achieving better product quality and safety.

Conclusion

The risk-based approach to validation is a best practice seen in guidance documents and used by best-in-class medical industry organizations, many of which are Jama Connect® customers. In general, few tools require full validation but should have functionality confirmed through a subset of tests, the scope of which is determined based on the potential risk to the patient or product.

When your organization implements Jama Connect, consider consulting GAMP®5 guidance to avoid non-value-added over-validation and unnecessary constraints on your processes and systems.

DOD 5000

DOD 5000 Series

DOD 5000 Series consists of policy guidance and is backed by a collection of directives that describe a disciplined management approach for acquiring systems and materiel to satisfy valid military needs.

Six pathways of the adaptive acquisition framework: urgent capability acquisition; middle tier of acquisition (MTA); major capability acquisition; software acquisition; defense business systems (DBS); and defense acquisition of services. Up until a few years ago, it used to be that every program large and small had to follow the exact same acquisition process. Today, programs that are small and short-lived can follow a different process than that of a large multi-decade weapons system acquisition program. DOD 5000.02 policy encourages program managers to tailor, combine, and transition between pathways to create their own program strategies.

All programs regardless of the pathway share functional areas that must be considered during program execution. Acquisition Intelligence, Cybersecurity, Intellectual Property (IP) Policy, Mission Engineering, Systems Engineering, and Test & Evaluation are key areas every program must practice. Digital Engineering is a key constituent of program execution, and its vision is articulated by the Department of Defense 2018 Digital Engineering Strategy. It clearly highlights model-based systems engineering (MBSE) as a new approach to take. Digital Engineering crosses these functional areas and is where Jama Connect® assists program managers the most.

RELATED: Jama Connect®: Accelerating Systems Development with Requirements Management and Live Traceability™

Jama Connect® gives program managers and their acquisition team the ability to use Digital Engineering MBSE right from the start in an easy-to-use browser interface

The early phases of all DOD 5000.02 acquisition pathways require the definition of mission capabilities and needs. Instead of capturing this information in Word, Excel, or a SysML tool which requires a deep level of expertise; the Jama Connect solution will provide an Excel and Word-like experience but also segregate data as discrete model elements. An early acquisition MBSE approach in Jama Connect provides numerous benefits to the program team such as categorization of information; prioritization; version history of changes; status monitoring through workflow; real-time metrics on dashboards; exportable dashboard widgets for PowerPoint presentations; built-in document generation; activity monitoring; and more.

These MBSE data capabilities provide real-time monitoring of progress of the definition of mission needs and capabilities and more importantly gives all stakeholders the opportunity to participate in the capture and writing of the data. The learning curve of Jama Connect is five minutes to half a day compared to six months for SysML tools. This is especially important when there are urgent operational needs and other quick reaction capabilities need to be acquired. DoDD 5000.71 and DoDI 5000.81 both provide instruction for program management techniques to follow.

Jama Connect dashboard widgets.

DOD 5000.02 Acquisition Lifecycles

DOD 5000.02 instructions call for numerous reviews to take place throughout the acquisition lifecycles.

Acquisition Intelligence example use case: DOD 5000.86 Instruction provides policy and guidance on how to integrate intelligence information into the acquisition lifecycle. Typically, this is performed as a siloed activity with information captured in documents, passed back and forth, and reviews taking place in face-to-face meetings. Jama Connect enables the extension of the needs and requirements in the MBSE data model to threats, adversary capabilities, and adversary intentions. Jama Connect’s Live Traceability™ gives the program and intelligence teams the ability to share information and analyze it in a single model. Contextual collaboration mechanisms such as Review Center reduce cycle times spent on document review and approval. This integration of intelligence supports: (1) Characterization of the threat. (2) Identification of intelligence supportability plans, risks, and cost drivers. (3) Residual risk to inform stakeholders.

Cybersecurity example use case: DOD 5000.90 Instruction provides policy and guidance on how to incorporate cyber threat information produced by the Intelligence Community in development of their cyber security strategy and assessment of risk. Jama Connect lets the acquisition team see the relationships between designs and architectures and the identified risks. Live Traceability enables more informed decision making and could act as a conduit to the risk management framework (RMF) system. When new threats emerge, Jama Connect can provide instant impact analysis to a program’s existing mission requirements.

Systems Engineering example: DoDI 5000.88 begins by stating that engineering begins “at the identification of a military need and continues throughout sustainment of the end item.” Jama Connect can be used during all phases of the acquisition lifecycle and allows a systems engineering discipline to become central to program management rather than a siloed activity. Mission needs are captured in Jama Connect as discrete elements rather than Word documents or PowerPoint slides and can be reviewed, approved, and captured in the concept baseline. An element approach (aka digital engineering) allows for the easy consumption of data by digital tools in the tool ecosystem.

As ME products are developed in response to the mission needs and provide mission-based inputs to the requirements process, Jama Connect will establish trace relationships between needs, ME products, and the requirements. Live Traceability gives the ability for any stakeholder at any time to see the most up to date and complete upstream and downstream information for any requirement — no matter the stage of systems development or how many siloed tools and teams it spans. This enables the engineering process to be managed through data, and its performance improved in real time.

DoDI5000.88 calls for many technical and assessments throughout the life of a program. Digital engineering reviews in Jama Connect give the technical and non-technical engineer to not only redline, comment on, provide approval for the data itself, but allows for teams to give traceable reference. If the technical review is that of requirements, then reviewers would have the context to see the related mission needs, any analysis, architecture, any tests, as well as understand the evolution of change to each individual requirement in that review. Reviews in this manner provide significant reduction of cycle times and retains a traceable audit trail of commentors and approvers.

Jama Connect Review Center

Jama Connect Review Center, participant progress view.

RELATED: Ensure Product Quality with These Review Process Best Practices

Conclusion

Jama Connect can provide capabilities to assist government program management teams execute parts of the adaptive acquisition framework and tie together information via Live Traceability and collaboration mechanisms. Program decisions are informed by real time data and is accessible to engineering and non-engineering stakeholders alike.

In summary, there are many opportunities to use Jama Connect as a key enabler of Digital Engineering across all phases of the adaptive acquisition framework no matter which pathway is chosen.

Risk Traceability

Incorporating Risk Traceability into Manufacturing Production Software and Preparing for the Transition from CSV to CSA

Intro

Over the years, the burden of Computer Systems Validation (CSV) has resulted in medical device manufacturers avoiding implementation of automated manufacturing production systems or upgrading long-outdated versions of software. As part of the FDA’s ‘Case for Quality’ initiative in 2011 to study quality best practice in medical device manufacturing, the FDA found that the burden of compliance, such what is expected for Computer Systems Validation (CSV), deterred technology investments and as a result, inhibited quality best-practice.

As an outcome, the FDA is expected to release a draft guidance in 2022 that outlines their new approach of Computer Software Assurance (CSA) for Production and Quality System Software. The goal is to improve software quality by focusing on the software’s impact to patient safety, impact to product quality, and impact to quality system integrity. Using a risk-based approach, manufacturers can spend more time testing to ensure software meets its intended use, instead of ensuring test protocols and reports are fully scripted are error free.

As the key to right-sizing CSA activities is based on risk, managing risk, and risk traceability and incorporating is a key activity. And there’s no need to wait for the publication of the FDA CSA draft guidance, medical device manufacturers can incorporate these risk management and traceability practices now in their CSV activities.

Keep reading below for best practices on how to extend risk management and risk traceability from the medical device development to your manufacturing production software used to manufacture your devices.

Main Points for How

Consider the product risks and hazards

Even though we are discussing manufacturing production software and the software used on manufacturing equipment, the first step is to consider the product risks and hazards. Start with your master list of hazards, hazardous situations, and associated harms developed during medical device development and determine where and how failures in the manufacturing production software and production equipment can result in those risks and hazards. These are the areas to consider as the highest risks to control, mitigate, and validate.

Next, perform additional risk analysis from the lens of the environment and manufacturing personnel that will operate said equipment and software. It is important to also protect the environment and prevent injury and harm to those interacting with the equipment. You don’t want the unintended release of hazardous chemical reagents or equipment fires that could have been prevented with built-in high temperature shut-down feature.

RELATED: Managing Complexity in Systems Engineering for Product Development with Live Traceability

Create manufacturing production software intended uses and requirements

Just as one determines the intended use and design input requirements of a medical device, the same is to be done for the manufacturing production software and equipment. Incorporate the necessary features as manufacturing requirements (analogous to the design inputs of your medical device) that address the risks identified in the previous step.

One example is based on risk of the product and demonstrates how risk traces from the development of the medical device. Consider the design of a semi-automated assembly machine for a drug-delivery device. The machine aligns and press-fits together two plastic injection-molded halves of the delivery sub-assembly. One of the main product associated risks is ensuring proper flow efficiency to ensure the proper amount of drug is delivered correctly and to the proper anatomical location.

In this case the risk traceability and translation to the assembly machine design inputs is:

RELATED: Application of Risk Analysis Techniques in Jama Connect® to Satisfy ISO 14971

Perform software testing and equipment validation based on risk

Once ready to test the production equipment software and perform equipment validation, incorporate, you guessed it, risk. All manufacturing requirements then need to be verified, however, scale the amount and type of testing for each manufacturing requirement based on the risk. Aspects of the software and equipment that are of high risk, such as preventing severe harm to operators, or the end users and patients of the medical device will have more testing and documentation than those of lower risk.

Document risk traceability of testing and equipment validation

Just as documenting risk traceability for medical device is important, it’s also important for manufacturing production software and equipment. Using a tool like Jama Connect® makes it easy to link your master list of hazards, hazardous situations, and harms to your manufacturing requirements for manufacturing production software and equipment. This increases consistency and efficiency in the risk analysis and prioritizing efforts on where it matters for patient and operator safety. The interface of Jama Connect® also makes the traceability and documentation of the associated testing and validation easy to visualize, alerting teams to gaps and incomplete testing.

Closing

Extending risk traceability from your medical device development to your manufacturing production software and equipment brings focus to what can impact patient safety and scales the testing and validation work appropriately. Incorporate risk and you’ll also be well on your way for the upcoming FDA transition from CSV to CSA.


Systems Engineering

Editor’s Note: This blog was originally published through IEEE Innovation at Work, “Managing Complexity in Systems Engineering for Product Development with Live Traceability,” by author Nikhil Rai, IEEE Senior Member, Senior Director of Product and Solutions Marketing at Jama Software.

Systems Engineering for Product Development with Live Traceability

Complexity of Product Development is Exploding

In today’s world, technological innovations across embedded systems, the Internet of Things (IoT), and artificial intelligence (AI) are aggressively pushing the envelope on product complexity and accelerating digital transformation. The next generation of autonomous cars, electric vehicles, robots, and space shuttles are all complex systems that need to seamlessly interact with multiple layers of software, hardware, and humans across different environments.

Because complex technology products require intricate interfaces with various systems or sub systems, there is an inherent challenge of coordinating the multiple development teams, who are often geographically spread across the world. Furthermore, large teams typically work on different stages of product development within their own silos. The different development tools, architecture, and IT environments used across various teams and organizations can significantly add to the challenges of developing new technologies.

Manufacturing sectors will reap the AI technology benefits of enhanced monitoring and supply chain optimization. In financial institutions, AI techniques can be used to identify which transactions are likely to be fraudulent. Through AI, the industry could also adopt fast and accurate credit scoring while automating manually intense data management tasks. Disruptions in the transport and logistics realm could include autonomous trucking and delivery on the roads and automated picking in warehouses.

RELATED: Systems Engineers Career Path – How to Elevate

Reality of Today’s Complex Systems Development

Most complex system development starts with defining user needs and requirements, which involves design, software, and hardware teams developing deliverables that ultimately get tested and integrated for delivering the product. Given the disparate nature of these teams, there is an inherent need to optimize and continuously keep track of systems information from concept to development and delivery. However, there is often a gap in terms of how information is consumed across engineering departments, as well as its availability and traceability. The digital thread in engineering today is still a collection of different tools, which means traceability is usually accomplished in a cumbersome and manual fashion via time-consuming meetings and disconnected documents.

Challenges in Traceability

Traceability is a key both to product development and software engineering for tracking the systems development lifecycle. Helpful in achieving regulatory compliance, traceability can also be used within software engineering for running test cases and gaining valuable insights.

While some organizations make it a point to map product development stages and improve traceability to gain these benefits, traceability is often considered after-the-fact by others. This means that once an issue is identified, there is effort required to trace back where the error originally occurred to prevent that same failure from occurring in the future. This approach can cause multiple cost overruns, product delays, and inefficient management of change impacts. Think of addressing a car recall or fixing a complex medical device or industrial equipment— the costs can be enormous. By emphasizing the importance of traceability from the start, organizations can avoid the extra effort and cost associated with implementing it after an error has been made.

RELATED: Requirements Traceability – How to Go Live

Live Traceability™

The solution lies in bringing a practical approach of Live Traceability™ to the systems engineering world. Optimizing and measuring the systems development process with Live Traceability is a crucial competitive advantage that companies can leverage. For any complex product, systems, or software development, the requirements and user needs form the first level of abstraction. Live Traceability can be measured and monitored by using systems requirements as an anchor to manage information used in different stages of the systems development lifecycle.

At Jama Software, we define live requirements traceability as the ability for any engineer at any time to see the most up-to-date and complete upstream and downstream information for any requirement— no matter the stage of systems development or how many siloed tools and teams it spans. Live Traceability of system requirements is required by industry standards to ensure product safety and forms the foundation for digital engineering and model-based systems engineering. This enables the engineering process to be managed through data and its performance improved in real time.

Through better requirements management and a focus on traceability, companies can improve their systems development performance with higher quality products and improved cycle times. The industry is now embracing the idea that to improve engineering efficiency within the systems development process, we need to continuously monitor and measure traceability.