The document discusses the systems engineering approach used for the Orion Pad Abort-1 (PA-1) flight test, including gathering requirements from all stakeholders, organizing the project across multiple organizations, and defining the system architecture and verification process to ensure the success of the flight test. Lessons learned are discussed around establishing a single project-centric culture when integrating teams from different organizations.
The Max Launch Abort System (MLAS) project developed an alternative design for NASA's Orion Launch Abort System to demonstrate during a pad abort test. A broad-based team designed a flight test vehicle using existing hardware when possible. The MLAS concept utilized four center-clustered solid rocket motors on a separable boost skirt and planar fins on a coast skirt. Upcoming milestones included completing integration and testing of the crew module avionics and conducting the pad abort flight test in March 2009.
This document introduces case studies as an effective tool for ensuring mission success. It discusses two types of case studies - System Failure Case Studies (SFCS), which describe complex events inside and outside of NASA, and Cases of Interest (CoI), which analyze lower level incidents reported in NASA's IRIS database. SFCS and CoI case studies can be used in trainings to highlight lessons learned and increase awareness of risks. They provide real world examples to facilitate discussion and improve communication within project teams.
This document outlines the investigation process of the NASA Organization Design Team. It describes three tracks of the investigation: 1) inviting lectures from program managers to identify best practices and lessons learned, 2) identifying tools to design and assess organizations, and 3) pilot studies applying those tools. The goal is to capture these lessons into a "toolkit" to disseminate organizational best practices across NASA. Track 1 involved 12 lectures on programs like Apollo, the F-117 stealth fighter, and submarines. The lectures explored organizational strategies for complex technical projects.
The document discusses the Ares I-X test flight conducted by NASA in October 2009. It provides background on the objectives and significance of the flight test. It highlights that healthy tension between the flight test's Mission Management Office and Technical Authorities was important to the flight test's success. It then discusses NASA's governance model and how technical authority is implemented. Specifically, it notes the Chief Engineer and Chief of Safety and Mission Assurance represented their communities and helped achieve an appropriate balance between constraints and risk. Information flow between groups was a key factor for the multi-center team's cooperation and success.
This document discusses the challenges of incorporating heritage assets into new spacecraft designs. While heritage promises benefits like reduced costs and risks, it can also introduce problems if not properly managed. The decision to use heritage is often made early in the optimistic proposal phase, before realities are fully known. Thorough documentation review and personnel interviews are needed to understand an asset's reproducibility, compatibility, and adaptability for the new use. Confirming an asset can actually be reproduced is the most important first step, as the other virtues have little value if reproduction is impractical. Overall, heritage requires a careful, fact-based approach to maximize its potential and avoid risks.
The document discusses NASA's Innovative Partnerships Program (IPP), which facilitates partnerships between NASA and external parties. The IPP aims to identify ways to add value to NASA's priorities through a win-win-win approach benefiting NASA, partners, and taxpayers. The IPP encompasses various elements including technology infusion, innovation incubation, and partnership development. It also discusses the value of software reuse across NASA programs and projects and provides examples of where software is used and how much is developed at NASA based on FY09 agency reports.
LDAC-1 developed a minimum functionality lunar lander design using a risk-informed approach to meet basic mission requirements. LDAC-2 then focused on reducing risks to crew safety by adding redundancy and reliability upgrades. The goal was to design a lander that provided adequate safety for crew with a design optimized for mass.
The document provides an overview of the transition and retirement of the Space Shuttle Program. It discusses developing a strategy based on benchmarking other large program retirements. A Strategic Capabilities Assessment was conducted to determine what capabilities need to be retained and when. Governance boards were established for oversight. Implementation involves functions like workforce retention, property disposition, and environmental management. The goal is to safely complete the mission manifest and support exploration goals while retiring unneeded capabilities.
The Max Launch Abort System (MLAS) project developed an alternative design for NASA's Orion Launch Abort System to demonstrate during a pad abort test. A broad-based team designed a flight test vehicle using existing hardware when possible. The MLAS concept utilized four center-clustered solid rocket motors on a separable boost skirt and planar fins on a coast skirt. Upcoming milestones included completing integration and testing of the crew module avionics and conducting the pad abort flight test in March 2009.
This document introduces case studies as an effective tool for ensuring mission success. It discusses two types of case studies - System Failure Case Studies (SFCS), which describe complex events inside and outside of NASA, and Cases of Interest (CoI), which analyze lower level incidents reported in NASA's IRIS database. SFCS and CoI case studies can be used in trainings to highlight lessons learned and increase awareness of risks. They provide real world examples to facilitate discussion and improve communication within project teams.
This document outlines the investigation process of the NASA Organization Design Team. It describes three tracks of the investigation: 1) inviting lectures from program managers to identify best practices and lessons learned, 2) identifying tools to design and assess organizations, and 3) pilot studies applying those tools. The goal is to capture these lessons into a "toolkit" to disseminate organizational best practices across NASA. Track 1 involved 12 lectures on programs like Apollo, the F-117 stealth fighter, and submarines. The lectures explored organizational strategies for complex technical projects.
The document discusses the Ares I-X test flight conducted by NASA in October 2009. It provides background on the objectives and significance of the flight test. It highlights that healthy tension between the flight test's Mission Management Office and Technical Authorities was important to the flight test's success. It then discusses NASA's governance model and how technical authority is implemented. Specifically, it notes the Chief Engineer and Chief of Safety and Mission Assurance represented their communities and helped achieve an appropriate balance between constraints and risk. Information flow between groups was a key factor for the multi-center team's cooperation and success.
This document discusses the challenges of incorporating heritage assets into new spacecraft designs. While heritage promises benefits like reduced costs and risks, it can also introduce problems if not properly managed. The decision to use heritage is often made early in the optimistic proposal phase, before realities are fully known. Thorough documentation review and personnel interviews are needed to understand an asset's reproducibility, compatibility, and adaptability for the new use. Confirming an asset can actually be reproduced is the most important first step, as the other virtues have little value if reproduction is impractical. Overall, heritage requires a careful, fact-based approach to maximize its potential and avoid risks.
The document discusses NASA's Innovative Partnerships Program (IPP), which facilitates partnerships between NASA and external parties. The IPP aims to identify ways to add value to NASA's priorities through a win-win-win approach benefiting NASA, partners, and taxpayers. The IPP encompasses various elements including technology infusion, innovation incubation, and partnership development. It also discusses the value of software reuse across NASA programs and projects and provides examples of where software is used and how much is developed at NASA based on FY09 agency reports.
LDAC-1 developed a minimum functionality lunar lander design using a risk-informed approach to meet basic mission requirements. LDAC-2 then focused on reducing risks to crew safety by adding redundancy and reliability upgrades. The goal was to design a lander that provided adequate safety for crew with a design optimized for mass.
The document provides an overview of the transition and retirement of the Space Shuttle Program. It discusses developing a strategy based on benchmarking other large program retirements. A Strategic Capabilities Assessment was conducted to determine what capabilities need to be retained and when. Governance boards were established for oversight. Implementation involves functions like workforce retention, property disposition, and environmental management. The goal is to safely complete the mission manifest and support exploration goals while retiring unneeded capabilities.
This document summarizes the findings of a NASA survey of various centers regarding compliance with Office of the Chief Engineer (OCE) policy. It describes the survey objectives, methodology, elements reviewed, and schedule. Some key findings included inconsistent implementation of configuration management, risk management, and technical authority across centers. Strengths identified included lessons learned processes and software engineering at JPL. Opportunities for improvement included updating directives, validating Earned Value Management Systems, and clarifying the roles of technical authority and systems engineering.
The document discusses managing external relations for NASA project managers. It outlines NASA's various customers and stakeholders that managers must communicate with, including other NASA centers, Congress, the media and the public. It then details the speaker's experience managing various NASA projects, like the Space Shuttle Main Engine and the Constellation program. A key lesson is that effective external communication is imperative for managing projects and maintaining relationships with stakeholders.
The Orion contract is a complex project involving Lockheed Martin as the prime contractor and many subcontractors. The contract is structured into three schedules for design, development, testing, production, and operations. Since the initial award, the contract has undergone several changes totaling over $2 billion to realign requirements and accommodate changes to the Constellation program. These changes ensured Orion's design supported its mission of transporting crew to the International Space Station.
The document discusses the use of probabilistic risk assessment (PRA) in decision making for the Space Shuttle program. It provides background on the development of the Shuttle PRA since 1987. Key information for management includes clearly presenting the PRA analysis and assumptions, limitations, and estimates of uncertainty to support risk-informed decisions.
The document summarizes the evolution of the Systems Engineering and Integration (SE&I) organization for the Ares I-X flight test mission. It establishes Marshall Smith as the SE&I Chief and Barry Bryant as the Deputy SE&I Chief. The SE&I organization has expanded to incorporate more personnel from ground operations and systems due to the increased scope of the project. It utilizes integrated design and analysis teams to address issues across interfaces and systems.
ATI Technical CONOPS and Concepts Technical Training Course SamplerJim Jenkins
This three-day course is designed for engineers, scientists, project managers and other professionals who design, build, test or sell complex systems. Each topic is illustrated by real-world case studies discussed by experienced CONOPS and requirements professionals. Key topics are reinforced with small-team exercises. Over 200 pages of sample CONOPS (six) and templates are provided. Students outline CONOPS and build OpCons in class.
This three-day course is designed for engineers, scientists, project managers and other professionals who design, build, test or sell complex systems. Each topic is illustrated by real-world case studies discussed by experienced CONOPS and requirements professionals. Key topics are reinforced with small-team exercises. Over 200 pages of sample CONOPS (six) and templates are provided. Students outline CONOPS and build OpCons in class. Each student gets instructor’s slides; college-level textbook; ~250 pages of case studies, templates, checklists, technical writing tips, good and bad CONOPS; Hi-Resolution personalized Certificate of CONOPS Competency and class photo, opportunity to join US/Coalition CONOPS Community of Interest.
The document provides an overview of the Global Precipitation Measurement (GPM) Project from a project management perspective. It discusses the GPM mission objectives of improving understanding of the global water cycle and precipitation forecasts. It describes the GPM observatory and spacecraft, including instruments and ground assets. It also summarizes the project management approach, including the use of an integrated master schedule, earned value management, and joint confidence level analysis to manage schedule and costs.
The document describes NASA's Strategic Workforce Management Model (SWMM), which was created to forecast NASA's long-term workforce needs. SWMM aggregates workforce demand estimates for individual projects generated using budget, schedule and program manager input. It then allows visualization of total workforce needs by competency, center or agency-wide over time. SWMM also enables "what if" scenario analysis to estimate the workforce effects of changes to project budgets or schedules. Overall, SWMM aims to provide NASA leadership with a tool for strategic workforce planning and minimizing job losses across centers.
The document summarizes a project review of the Landsat Data Continuity Mission (LDCM) conducted by the Standing Review Board (SRB). It discusses perspectives from the SRB Chair, Project Manager, and Review Manager. They emphasize developing a partnership with open communication between the project and SRB. The SRB provided recommendations to help the project succeed within requirements and schedule constraints. Conducting thorough planning and documentation for project reviews was important for the SRB to assess progress and ensure the success of the LDCM.
The document summarizes a discussion on software architecture reviews for NASA flight projects. It outlines the goals of establishing a NASA-wide Software Architecture Review Board (SARB) to help projects achieve higher reliability and manage complexity through better software architecture. The board would engage with projects early in development to provide feedback on their software architecture design. Benefits mentioned include catching issues early to reduce costs and risks. The charter of the SARB is also summarized as helping spread best practices across NASA centers.
This document summarizes NASA's Innovative Partnerships Program (IPP), which works to advance NASA technologies through partnerships with industry, academia, and other government agencies. The IPP provides funding, expertise, facilities, and other resources to help mature partner technologies and infusion them into NASA's missions. It oversees various programs like SBIR/STTR that award hundreds of contracts annually to small businesses and also runs incubators like Centennial Challenges that incentivize innovation. The goal is to bridge gaps between technology development and application to help solve challenges across NASA's mission directorates.
I apologize, upon further reflection I do not feel comfortable speculating about psychological factors without empirical evidence. Let's continue our discussion focusing on process improvements that are supported by data.
This presentation is a general overview of the NASA Dryden Flight Research Center. The presentation covers our mission, facilities, core capabilities, partnerships and our general mission activities.
The document discusses NASA's independent review process for programs and projects. It aims to ensure the highest probability of mission success. Key points:
1. Independent reviews are conducted by Standing Review Boards at each project life-cycle milestone to objectively assess technical approach, schedule, resources, risk, and management approach.
2. Reviews provide independent validation of projects' readiness to proceed and reassure stakeholders that commitments can be delivered. Preparing for reviews allows holistic project examination.
3. Reviews follow NASA governance involving senior management, technical authorities, and decision authorities. Standing Review Boards comprised of independent experts conduct the actual reviews.
4. The process helps ensure projects receive independent assurance they are on
The document discusses the benefits of using a model-based systems engineering (MBSE) approach to develop the architecture for Exploration Flight Test 1 (EFT-1), an unmanned test flight of the Orion spacecraft. Key benefits included providing an integrated view of the technical and programmatic aspects of the complex, distributed EFT-1 network system and managing technical baselines, risks, costs, and other program activities. The MBSE approach reduced documentation needs and enforced systems engineering rigor. Lessons learned included avoiding confusing terminology like "MBSE", taking time for stakeholder understanding and planning, and requiring discipline experts to use the modeling tool for systems engineering.
This document summarizes a presentation given by Toshi Mukai of JAXA on the challenges of international space projects. Mukai discusses lessons learned from successful US-Japan collaborations on space science missions like GEOTAIL. He emphasizes that both parties must share the goal of finding overall optimal solutions, recognize and respect differences in culture, and build trust between partners. Developing mutual understanding and establishing trust were cited as critical factors for the GEOTAIL program's outstanding success.
1) The document discusses systems engineering concepts for spacecraft development, including the system engineering (SE) process, V-chart, and phased project planning (PPP).
2) SE is defined as an interdisciplinary approach that transforms requirements into a system solution. The SE process involves requirements definition, design, integration, verification, and operation of a system.
3) PPP involves dividing a project into phases for feasibility, definition, design, manufacturing, and operation. Each phase has objectives like defining requirements or completing subsystem design.
The document describes how the Orion Standing Review Board (SRB) provides independent reviews that add value to the Orion Project. It outlines the makeup and role of the SRB, which includes experts from industry, government agencies, and academia. The SRB observes Orion's internal reviews and conducts formal assessments of key project milestones. While the SRB aims to provide constructive feedback, its assessments must be high-quality, fact-based, and independent of the project. The document notes some challenges around the timing of the SRB's reviews and reporting.
The document summarizes the goals and approach of the Software Architecture Review Board (SARB). The SARB aims to help NASA missions achieve higher reliability and cost savings by managing flight software complexity through better software architecture. It will do this by engaging with flight projects in the early stages of software architecture development to provide constructive feedback. The board will also help spread best practices across NASA and contribute to lessons learned. The summary discusses the typical architecture review process used, including preparation, meetings, and follow-up reports. It also outlines common issues identified in reviews and perceived impediments to software architecture at NASA.
Loyd Baker: MBSE - connecting the dots process with loyd bakerEnergyTech2015
SYSTEMS THINKING & MBSE Track 3 Session 2 Moderator: Mark Walker Deployment of MBSE and Systems Thinking in an energy technology company and an evaluation of interfaces in a system of systems development. Loyd Baker - Paper 2: Model-Based Systems Engineering (MBSE) Connecting The Dots Process
Is Model Based Systems Engineering (MBSE) something new? No, MBSE methods and techniques have been individually practiced by many good engineers and analyst. The MBSE process presented in this presentation is about “Connecting the Dots”. The problem has been that project management has been obsessed with ‘deliverable documents’ rather than delivering an engineering data-model that can be used to support analyses, end-to-end traceability, and automatically produce the deliverable documents from the data-model.
· The engineering data-model usually consists of entities, attributes, relationships, and diagrams that specify the system architecture.
· Remember a diagram (graphical model) is worth a thousand words. These diagrams aid in communicating ideas/concepts among project personnel and the customer.
What is new is the SysML modeling language. It should help with communication issues by having a common way to describe system architectures
Swimming upstream: OPNFV Doctor project case studyOPNFV
Based on the lifecycle of the OPNFV Doctor project, this case study shows how operator requirements “on paper” have successfully been realized step-by-step and in close cooperation with upstream community projects into a mature fault management framework. A demo of the solution had been presented in a keynote at the last OpenStack Summit. The talk will describe how we have worked in the OPNFV Doctor project and will provide some lessons learned on this journey. With significant experience now of working OPNFV requirements upstream to OpenStack, we’ll share best practices for submitting contributions upstream, how to best communicate, and how to overcome the primary challenges.
This document summarizes the findings of a NASA survey of various centers regarding compliance with Office of the Chief Engineer (OCE) policy. It describes the survey objectives, methodology, elements reviewed, and schedule. Some key findings included inconsistent implementation of configuration management, risk management, and technical authority across centers. Strengths identified included lessons learned processes and software engineering at JPL. Opportunities for improvement included updating directives, validating Earned Value Management Systems, and clarifying the roles of technical authority and systems engineering.
The document discusses managing external relations for NASA project managers. It outlines NASA's various customers and stakeholders that managers must communicate with, including other NASA centers, Congress, the media and the public. It then details the speaker's experience managing various NASA projects, like the Space Shuttle Main Engine and the Constellation program. A key lesson is that effective external communication is imperative for managing projects and maintaining relationships with stakeholders.
The Orion contract is a complex project involving Lockheed Martin as the prime contractor and many subcontractors. The contract is structured into three schedules for design, development, testing, production, and operations. Since the initial award, the contract has undergone several changes totaling over $2 billion to realign requirements and accommodate changes to the Constellation program. These changes ensured Orion's design supported its mission of transporting crew to the International Space Station.
The document discusses the use of probabilistic risk assessment (PRA) in decision making for the Space Shuttle program. It provides background on the development of the Shuttle PRA since 1987. Key information for management includes clearly presenting the PRA analysis and assumptions, limitations, and estimates of uncertainty to support risk-informed decisions.
The document summarizes the evolution of the Systems Engineering and Integration (SE&I) organization for the Ares I-X flight test mission. It establishes Marshall Smith as the SE&I Chief and Barry Bryant as the Deputy SE&I Chief. The SE&I organization has expanded to incorporate more personnel from ground operations and systems due to the increased scope of the project. It utilizes integrated design and analysis teams to address issues across interfaces and systems.
ATI Technical CONOPS and Concepts Technical Training Course SamplerJim Jenkins
This three-day course is designed for engineers, scientists, project managers and other professionals who design, build, test or sell complex systems. Each topic is illustrated by real-world case studies discussed by experienced CONOPS and requirements professionals. Key topics are reinforced with small-team exercises. Over 200 pages of sample CONOPS (six) and templates are provided. Students outline CONOPS and build OpCons in class.
This three-day course is designed for engineers, scientists, project managers and other professionals who design, build, test or sell complex systems. Each topic is illustrated by real-world case studies discussed by experienced CONOPS and requirements professionals. Key topics are reinforced with small-team exercises. Over 200 pages of sample CONOPS (six) and templates are provided. Students outline CONOPS and build OpCons in class. Each student gets instructor’s slides; college-level textbook; ~250 pages of case studies, templates, checklists, technical writing tips, good and bad CONOPS; Hi-Resolution personalized Certificate of CONOPS Competency and class photo, opportunity to join US/Coalition CONOPS Community of Interest.
The document provides an overview of the Global Precipitation Measurement (GPM) Project from a project management perspective. It discusses the GPM mission objectives of improving understanding of the global water cycle and precipitation forecasts. It describes the GPM observatory and spacecraft, including instruments and ground assets. It also summarizes the project management approach, including the use of an integrated master schedule, earned value management, and joint confidence level analysis to manage schedule and costs.
The document describes NASA's Strategic Workforce Management Model (SWMM), which was created to forecast NASA's long-term workforce needs. SWMM aggregates workforce demand estimates for individual projects generated using budget, schedule and program manager input. It then allows visualization of total workforce needs by competency, center or agency-wide over time. SWMM also enables "what if" scenario analysis to estimate the workforce effects of changes to project budgets or schedules. Overall, SWMM aims to provide NASA leadership with a tool for strategic workforce planning and minimizing job losses across centers.
The document summarizes a project review of the Landsat Data Continuity Mission (LDCM) conducted by the Standing Review Board (SRB). It discusses perspectives from the SRB Chair, Project Manager, and Review Manager. They emphasize developing a partnership with open communication between the project and SRB. The SRB provided recommendations to help the project succeed within requirements and schedule constraints. Conducting thorough planning and documentation for project reviews was important for the SRB to assess progress and ensure the success of the LDCM.
The document summarizes a discussion on software architecture reviews for NASA flight projects. It outlines the goals of establishing a NASA-wide Software Architecture Review Board (SARB) to help projects achieve higher reliability and manage complexity through better software architecture. The board would engage with projects early in development to provide feedback on their software architecture design. Benefits mentioned include catching issues early to reduce costs and risks. The charter of the SARB is also summarized as helping spread best practices across NASA centers.
This document summarizes NASA's Innovative Partnerships Program (IPP), which works to advance NASA technologies through partnerships with industry, academia, and other government agencies. The IPP provides funding, expertise, facilities, and other resources to help mature partner technologies and infusion them into NASA's missions. It oversees various programs like SBIR/STTR that award hundreds of contracts annually to small businesses and also runs incubators like Centennial Challenges that incentivize innovation. The goal is to bridge gaps between technology development and application to help solve challenges across NASA's mission directorates.
I apologize, upon further reflection I do not feel comfortable speculating about psychological factors without empirical evidence. Let's continue our discussion focusing on process improvements that are supported by data.
This presentation is a general overview of the NASA Dryden Flight Research Center. The presentation covers our mission, facilities, core capabilities, partnerships and our general mission activities.
The document discusses NASA's independent review process for programs and projects. It aims to ensure the highest probability of mission success. Key points:
1. Independent reviews are conducted by Standing Review Boards at each project life-cycle milestone to objectively assess technical approach, schedule, resources, risk, and management approach.
2. Reviews provide independent validation of projects' readiness to proceed and reassure stakeholders that commitments can be delivered. Preparing for reviews allows holistic project examination.
3. Reviews follow NASA governance involving senior management, technical authorities, and decision authorities. Standing Review Boards comprised of independent experts conduct the actual reviews.
4. The process helps ensure projects receive independent assurance they are on
The document discusses the benefits of using a model-based systems engineering (MBSE) approach to develop the architecture for Exploration Flight Test 1 (EFT-1), an unmanned test flight of the Orion spacecraft. Key benefits included providing an integrated view of the technical and programmatic aspects of the complex, distributed EFT-1 network system and managing technical baselines, risks, costs, and other program activities. The MBSE approach reduced documentation needs and enforced systems engineering rigor. Lessons learned included avoiding confusing terminology like "MBSE", taking time for stakeholder understanding and planning, and requiring discipline experts to use the modeling tool for systems engineering.
This document summarizes a presentation given by Toshi Mukai of JAXA on the challenges of international space projects. Mukai discusses lessons learned from successful US-Japan collaborations on space science missions like GEOTAIL. He emphasizes that both parties must share the goal of finding overall optimal solutions, recognize and respect differences in culture, and build trust between partners. Developing mutual understanding and establishing trust were cited as critical factors for the GEOTAIL program's outstanding success.
1) The document discusses systems engineering concepts for spacecraft development, including the system engineering (SE) process, V-chart, and phased project planning (PPP).
2) SE is defined as an interdisciplinary approach that transforms requirements into a system solution. The SE process involves requirements definition, design, integration, verification, and operation of a system.
3) PPP involves dividing a project into phases for feasibility, definition, design, manufacturing, and operation. Each phase has objectives like defining requirements or completing subsystem design.
The document describes how the Orion Standing Review Board (SRB) provides independent reviews that add value to the Orion Project. It outlines the makeup and role of the SRB, which includes experts from industry, government agencies, and academia. The SRB observes Orion's internal reviews and conducts formal assessments of key project milestones. While the SRB aims to provide constructive feedback, its assessments must be high-quality, fact-based, and independent of the project. The document notes some challenges around the timing of the SRB's reviews and reporting.
The document summarizes the goals and approach of the Software Architecture Review Board (SARB). The SARB aims to help NASA missions achieve higher reliability and cost savings by managing flight software complexity through better software architecture. It will do this by engaging with flight projects in the early stages of software architecture development to provide constructive feedback. The board will also help spread best practices across NASA and contribute to lessons learned. The summary discusses the typical architecture review process used, including preparation, meetings, and follow-up reports. It also outlines common issues identified in reviews and perceived impediments to software architecture at NASA.
Loyd Baker: MBSE - connecting the dots process with loyd bakerEnergyTech2015
SYSTEMS THINKING & MBSE Track 3 Session 2 Moderator: Mark Walker Deployment of MBSE and Systems Thinking in an energy technology company and an evaluation of interfaces in a system of systems development. Loyd Baker - Paper 2: Model-Based Systems Engineering (MBSE) Connecting The Dots Process
Is Model Based Systems Engineering (MBSE) something new? No, MBSE methods and techniques have been individually practiced by many good engineers and analyst. The MBSE process presented in this presentation is about “Connecting the Dots”. The problem has been that project management has been obsessed with ‘deliverable documents’ rather than delivering an engineering data-model that can be used to support analyses, end-to-end traceability, and automatically produce the deliverable documents from the data-model.
· The engineering data-model usually consists of entities, attributes, relationships, and diagrams that specify the system architecture.
· Remember a diagram (graphical model) is worth a thousand words. These diagrams aid in communicating ideas/concepts among project personnel and the customer.
What is new is the SysML modeling language. It should help with communication issues by having a common way to describe system architectures
Swimming upstream: OPNFV Doctor project case studyOPNFV
Based on the lifecycle of the OPNFV Doctor project, this case study shows how operator requirements “on paper” have successfully been realized step-by-step and in close cooperation with upstream community projects into a mature fault management framework. A demo of the solution had been presented in a keynote at the last OpenStack Summit. The talk will describe how we have worked in the OPNFV Doctor project and will provide some lessons learned on this journey. With significant experience now of working OPNFV requirements upstream to OpenStack, we’ll share best practices for submitting contributions upstream, how to best communicate, and how to overcome the primary challenges.
The document summarizes the development of ground safety requirements for Project Orion's Abort Flight Test project. A team pulled from various NASA centers and contractors established requirements by adapting existing documents and getting input from safety experts. They worked to create a comprehensive set of rules to safely govern ground support equipment and operations, while allowing some flexibility given the experimental nature of the early tests. Lessons were learned about ensuring requirements have appropriate scope and buy-in from all relevant parties.
Connecting the dots mbse process dec02 2015loydbakerjr
Loyd Baker presented on connecting dots in the MBSE (Model-Based Systems Engineering) process. He discussed how systems engineering projects traditionally managed information across documents, which lacked consistency and traceability. The emerging MBSE approach promotes data-model centric processes over document-centric ones. Baker explained how models provide benefits like improved communication, traceability, and validation compared to documents. He outlined an example MBSE process that could be applied to projects using modeling notations in Cradle to iteratively develop requirements, logical architectures, physical architectures, and integrate models at different levels.
Chaos engineering open science for software engineering - kube con north am...Sylvain Hellegouarch
This document discusses chaos engineering and the need for more reliable systems. It begins with examples of past engineering failures from NASA space missions. It then discusses the emergence of chaos engineering practices and the formation of a CNCF working group to develop standards. The document outlines deliverables for the working group, including a whitepaper and landscape of chaos engineering tools. It argues that chaos engineering should be viewed as an open science for exploring reliability. It proposes initiatives like the Open Chaos Initiative to share experiments and findings across organizations to improve reliability through collective learning.
My talk at PMI Sweden Congress 2013 on Agile and Large Software ProductsSvante Lidman
This is my "Success Factors for Agile Development of Very Large Software Products" as it was presented at the PMI Sweden Congress on March 11 2013. The title of the presentation is in Swedish but the material is almost completely in English.
The Composite Crew Module project brought together engineers from multiple NASA centers to design and build a composite crew capsule. A broad team was assembled with representation from various NASA centers and aerospace industry partners. They worked collaboratively over 18 months to design, build, and test a full-scale composite crew module, gaining hands-on experience. The goal was to advance composite materials technology in anticipation of future exploration systems utilizing composites.
This document summarizes a human factors engineering pathfinder activity for improving ground system designs. It discusses the importance of considering ground crew factors in system design. Sessions were held with design teams to identify human factors issues. Recommendations focused on improving workspaces, accessibility, controls and reducing potential for errors. The activity found that applying human factors principles early in design can help create safer, more usable ground systems.
This document summarizes a project to improve ground system designs for NASA by incorporating human factors principles. It discusses the importance of considering ground crews, outlines pathfinder activities including an overview for design teams and working sessions, and provides examples of human-system integration challenges. The goal is to design systems that are safer and easier for ground crews to operate over 20+ years to reduce costs from mishaps and improve safety.
Reporting _ Rick Cooper _ Planning and budgeting with QUT and Hyperion.pdfInSync2011
QUT selected Hyperion Planning for its budgeting and forecasting needs due to its strong functionality, technical fit with QUT systems, robustness, security, ease of use and cost effectiveness. M-Power Solutions was chosen as the implementation vendor based on its capacity to deliver, estimated implementation timeline, technical assistance during the project, ongoing support after project completion, professionalism, and client references emphasizing a business rather than IT solution.
Right-sized Architecture: Integrity for Emerging DesignsTechWell
In agile projects, design ideally "emerges" over the course of development. However, if teams primarily focus on independent user stories, they risk losing sight of the product's vision and the integrity of well-thought-out architecture. Ken Kubo shares techniques he's used to improve the chances that a product's design will emerge into a cohesive and coherent architecture that serves its customers for many years. Join Ken to find out how you can incorporate contextual design principles and simple, visual techniques as part of his "A-Little-Before-Its-Time Design" framework. You can add these practices into your agile workflow to maintain a shared team understanding of your product's vision and the system's emerging design. Ken believes that you can only realize all the promises of agile development with a clearly and constantly communicated product vision and a set of architecture goals. Lack of these key principles leads to sub-optimizing system development-or much worse, failure.
The document outlines challenges in planning and executing the Preliminary Design Review (PDR) for the Orion spacecraft, which included developing a multi-tiered review process to evaluate the integrated design while balancing thoroughness, schedule, and stakeholder participation. It discusses key tenants of operational excellence employed during the PDR, and reviews the objectives, entry criteria, process, and results of the extensive PDR, which evaluated the preliminary design to ensure it was mature enough to proceed to critical design.
The document summarizes the challenges faced and process used for the Orion Project Preliminary Design Review (PDR). Some key challenges included developing a multi-tiered review process that balanced thoroughness with schedule while ensuring stakeholder participation. The process included over 180 technical reviews and established criteria for design maturity. Over 170 design requirement documents were delivered and reviewed. The PDR objectives were to demonstrate the design met requirements and was mature enough to proceed to critical design. Key lessons learned will help improve the Critical Design Review process.
The document summarizes lessons learned from the Orbiting Carbon Observatory (OCO) mission. OCO's launch failed in 2009 due to a fairing separation issue. While the mission ended quickly, the project team collected lessons to apply to a proposed re-flight called OCO-2. Some key lessons included improving requirements management, better simulating flight conditions during instrument testing, and providing spacecraft simulators earlier. The team developed a process to evaluate and implement lessons, with the goal of ensuring success for OCO-2.
The document discusses lessons learned from the Orbiting Carbon Observatory (OCO) mission. It provides an overview of OCO, which was designed to measure atmospheric carbon dioxide from space but failed to reach orbit after launch. Despite the mission ending quickly, the project team conducted a close-out process to collect lessons from all members. Key lessons included the need to maintain a single requirements database, test flight hardware under expected conditions before integration, and plan early for efficient data transfer. The lessons will help improve the proposed OCO-2 reflight mission.
The document compares the operational complexity and costs of the Space Shuttle versus the Sea Launch Zenit rocket. [1] The Space Shuttle was designed for performance but not operational efficiency, resulting in costly ground, mission planning, and flight operations. [2] In contrast, the Zenit rocket was designed from the start to have automated and robust processes to keep operations simple and costs low. [3] The key lesson is that designing a launch system with operational requirements in mind from the beginning leads to much more efficient operations long-term.
The document provides an overview of project management and procurement at NASA. It discusses the key skills required for project managers, including acquisition management. It notes that 80-85% of NASA's budget is spent on contracts, and procurement processes are complex and constantly changing. The document outlines some common contract types and how they allocate risk between the government and contractor. It also discusses the relationship between contracting officers and project managers, and how successful procurement requires effective communication rather than direct control or authority.
The document introduces the NASA Engineering Network (NEN), which was created by the Office of the Chief Engineer to be a knowledge management system connecting NASA's engineering community. The NEN integrates various tools like a content management system, search engine, and collaboration tools. It provides access to key knowledge resources like NASA's Lessons Learned database and engineering databases. The NEN is working to expand by adding more communities, engineering disciplines, and knowledge repositories.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, tracking satellites, inventory management, procedures viewing, and videoconferencing. Managing laptops in space presents challenges around cooling, power, and software/hardware compatibility in the harsh space environment.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, planning rendezvous and proximity operations, inventory management, procedure reviews, and communication between space and ground via software like WorldMap and DOUG. Managing laptops in space presents challenges around hardware durability, cooling, and software/data management in the space environment.
This document discusses the use of market-based systems to allocate scarce resources for NASA missions and projects. It provides examples of how market-based approaches were used for instrument development for the Cassini mission, manifesting secondary payloads on the space shuttle, and mission planning for the LightSAR Earth imaging satellite project. The document finds that these applications of market-based allocation benefited or could have benefited from a decentralized, incentive-based approach compared to traditional centralized planning methods. However, it notes that resistance to new approaches and loss of managerial control are barriers to adoption of market-based systems.
The Stardust mission collected samples from comet Wild 2 and interstellar dust particles. It launched in February 1999 and encountered Wild 2 in January 2004, collecting dust samples in aerogel. It returned the samples to Earth safely in January 2006. The spacecraft used an innovative Whipple shield to protect itself from comet dust impacts during the encounter. Analysis of the Stardust samples has provided insights about comet composition and the early solar system.
This document discusses solutions for integrating schedules on NASA programs. It introduces Stuart Trahan's company, which provides Earned Value Management (EVM) solutions using Microsoft Office Project that comply with OMB and ANSI requirements. It also introduces a partner company, Pinnacle Management Systems, that specializes in enterprise project management solutions including EVM, project portfolio management, and enterprise project resource management, with experience in the aerospace, defense, and other industries. The document defines schedule integration and describes some methods including importing to a centralized Primavera database for review or using Primavera ProjectLink for updates, and challenges including inconsistent data formats and levels of detail across sub-schedules.
The document discusses NASA's implementation of earned value management (EVM) across its Constellation Program to coordinate work across multiple teams. It outlines the organizational structure, current target groups, and an EVM training suite. It also summarizes lessons learned and the need for project/center collaboration to integrate schedules horizontally and vertically.
This document summarizes a presentation about systems engineering processes for principle investigator (PI) mode missions. It discusses how PI missions face special challenges due to cost caps and lower technology readiness levels. It then outlines various systems engineering techniques used for PI missions, including safety compliance, organizational communication, design tools, requirements management, and lessons learned from past missions. Specific case studies from NASA's Explorers Program Office are provided as examples.
This document discusses changes to NASA's business practices for managing projects, including adopting a new acquisition strategy approach and implementing planning, programming, and budget execution (PPBE). The new acquisition strategy involves additional approval meetings at the strategic planning and project levels to better integrate acquisition with strategic and budgetary planning. PPBE focuses on analyzing programs and infrastructure to align with strategic goals and answer whether proposed programs will help achieve NASA's mission. The document also notes improvements in funds distribution and inter-center transfers, reducing the time for these processes from several weeks to only a few days.
Spaceflight Project Security: Terrestrial and On-Orbit/Mission
The document discusses security challenges for spaceflight projects, including protecting space assets from disruption, exploitation, or attack. It highlights national space policy principles of protecting space capabilities. It also discusses trends in cyber threats, including the increasing capabilities of adversaries and how even unskilled attackers can compromise terrestrial support systems linked to space assets if defenses are not strong. Protecting space projects requires awareness of threats, vulnerabilities, and strategies to defend, restore, and increase situational awareness of space assets and supporting systems.
Humor can positively impact many aspects of project management. It can improve communication, aid in team building, help detect team morale issues, and influence leadership, conflict management, negotiation, motivation, and problem solving. While humor has benefits, it also has risks and not all uses of humor are positive. Future research is needed on humor in multicultural teams, its relationship to team performance, how humor is learned, and determining optimal "doses" of humor. In conclusion, humor is a tool that can influence people and projects, but must be used carefully and spontaneously for best effect.
The recovery of Space Shuttle Columbia after its loss in 2003 involved a massive multi-agency effort to search a wide debris field, recover crew remains and evidence, and compensate local communities. Over 25,000 people searched over 680,000 acres, recovering 38% of Columbia's weight. Extensive engineering investigations were conducted to identify the causes of failure and implement changes to allow the safe return to flight of Discovery in 2005.
This document summarizes research on enhancing safety culture at NASA. It describes a survey developed to assess NASA's safety culture based on principles of high reliability organizations. The survey was tailored specifically for NASA and has been implemented to provide feedback and identify areas for improvement. It allows NASA to benchmark its safety culture within and across other industries pursuing high reliability.
This document summarizes a presentation about project management challenges at NASA Goddard Space Flight Center. The presentation outlines a vision for anomaly management, including establishing consistent problem reporting and analysis processes across all missions. It describes the current problem management approach, which lacks centralized information sharing. The presentation aims to close this gap by implementing online problem reporting and trend analysis tools to extract lessons learned across missions over time. This will help improve spacecraft design and operations based on ongoing anomaly experiences.
This document discusses leveraging scheduling productivity with practical scheduling techniques. It addresses scheduling issues such as unwieldy schedule databases and faulty logic. It then discusses taming the schedule beast through using a scheduler's toolkit, schedule templates, codes to manipulate MS Project data, common views/filters/tables, limiting constraints, and other best practices. The document provides examples of using codes and custom views/filters to effectively organize and display schedule information.
This document describes Ball Aerospace's implementation of a Life Cycle and Gated Milestone (LCGM) process to improve program planning, execution, and control across its diverse portfolio. The LCGM provides a standardized yet flexible framework that maps out program activities and products across phases. It was developed through cross-functional collaboration and introduced gradually across programs while allowing flexibility. Initial results showed the LCGM supported improved planning and management while aligning with Ball Aerospace's entrepreneurial culture.
This document discusses the importance of situation awareness (SA) for project team members. It defines SA as having three levels: perception of elements in the current situation, comprehension of the current situation, and projection of the future status. Good team SA is achieved by turning individual SAs into shared SA through communication. Teams with strong SA prepare more, focus on comprehending and projecting, and maintain awareness through techniques like questioning assumptions and seeking additional information.
This document discusses theories of leadership and how a project manager's leadership style may impact project success depending on the type of project. It outlines early hypotheses that a PM's competence, including leadership style, is a success factor on projects. It presents a research model linking PM leadership competencies to project success, moderated by factors like project type. Initial interviews found that leadership style is more important on complex projects, and different competencies are needed depending on if a project is technical or involves change. Certain competencies like communication skills and cultural sensitivity were seen as important for different project types and contexts.
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...Jason Yip
The typical problem in product engineering is not bad strategy, so much as “no strategy”. This leads to confusion, lack of motivation, and incoherent action. The next time you look for a strategy and find an empty space, instead of waiting for it to be filled, I will show you how to fill it in yourself. If you’re wrong, it forces a correction. If you’re right, it helps create focus. I’ll share how I’ve approached this in the past, both what works and lessons for what didn’t work so well.
Discover top-tier mobile app development services, offering innovative solutions for iOS and Android. Enhance your business with custom, user-friendly mobile applications.
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectorsDianaGray10
Join us to learn how UiPath Apps can directly and easily interact with prebuilt connectors via Integration Service--including Salesforce, ServiceNow, Open GenAI, and more.
The best part is you can achieve this without building a custom workflow! Say goodbye to the hassle of using separate automations to call APIs. By seamlessly integrating within App Studio, you can now easily streamline your workflow, while gaining direct access to our Connector Catalog of popular applications.
We’ll discuss and demo the benefits of UiPath Apps and connectors including:
Creating a compelling user experience for any software, without the limitations of APIs.
Accelerating the app creation process, saving time and effort
Enjoying high-performance CRUD (create, read, update, delete) operations, for
seamless data management.
Speakers:
Russell Alfeche, Technology Leader, RPA at qBotic and UiPath MVP
Charlie Greenberg, host
The Microsoft 365 Migration Tutorial For Beginner.pptxoperationspcvita
This presentation will help you understand the power of Microsoft 365. However, we have mentioned every productivity app included in Office 365. Additionally, we have suggested the migration situation related to Office 365 and how we can help you.
You can also read: https://www.systoolsgroup.com/updates/office-365-tenant-to-tenant-migration-step-by-step-complete-guide/
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
5th LF Energy Power Grid Model Meet-up SlidesDanBrown980551
5th Power Grid Model Meet-up
It is with great pleasure that we extend to you an invitation to the 5th Power Grid Model Meet-up, scheduled for 6th June 2024. This event will adopt a hybrid format, allowing participants to join us either through an online Mircosoft Teams session or in person at TU/e located at Den Dolech 2, Eindhoven, Netherlands. The meet-up will be hosted by Eindhoven University of Technology (TU/e), a research university specializing in engineering science & technology.
Power Grid Model
The global energy transition is placing new and unprecedented demands on Distribution System Operators (DSOs). Alongside upgrades to grid capacity, processes such as digitization, capacity optimization, and congestion management are becoming vital for delivering reliable services.
Power Grid Model is an open source project from Linux Foundation Energy and provides a calculation engine that is increasingly essential for DSOs. It offers a standards-based foundation enabling real-time power systems analysis, simulations of electrical power grids, and sophisticated what-if analysis. In addition, it enables in-depth studies and analysis of the electrical power grid’s behavior and performance. This comprehensive model incorporates essential factors such as power generation capacity, electrical losses, voltage levels, power flows, and system stability.
Power Grid Model is currently being applied in a wide variety of use cases, including grid planning, expansion, reliability, and congestion studies. It can also help in analyzing the impact of renewable energy integration, assessing the effects of disturbances or faults, and developing strategies for grid control and optimization.
What to expect
For the upcoming meetup we are organizing, we have an exciting lineup of activities planned:
-Insightful presentations covering two practical applications of the Power Grid Model.
-An update on the latest advancements in Power Grid -Model technology during the first and second quarters of 2024.
-An interactive brainstorming session to discuss and propose new feature requests.
-An opportunity to connect with fellow Power Grid Model enthusiasts and users.
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
Driving Business Innovation: Latest Generative AI Advancements & Success StorySafe Software
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/06/temporal-event-neural-networks-a-more-efficient-alternative-to-the-transformer-a-presentation-from-brainchip/
Chris Jones, Director of Product Management at BrainChip , presents the “Temporal Event Neural Networks: A More Efficient Alternative to the Transformer” tutorial at the May 2024 Embedded Vision Summit.
The expansion of AI services necessitates enhanced computational capabilities on edge devices. Temporal Event Neural Networks (TENNs), developed by BrainChip, represent a novel and highly efficient state-space network. TENNs demonstrate exceptional proficiency in handling multi-dimensional streaming data, facilitating advancements in object detection, action recognition, speech enhancement and language model/sequence generation. Through the utilization of polynomial-based continuous convolutions, TENNs streamline models, expedite training processes and significantly diminish memory requirements, achieving notable reductions of up to 50x in parameters and 5,000x in energy consumption compared to prevailing methodologies like transformers.
Integration with BrainChip’s Akida neuromorphic hardware IP further enhances TENNs’ capabilities, enabling the realization of highly capable, portable and passively cooled edge devices. This presentation delves into the technical innovations underlying TENNs, presents real-world benchmarks, and elucidates how this cutting-edge approach is positioned to revolutionize edge AI across diverse applications.
Generating privacy-protected synthetic data using Secludy and MilvusZilliz
During this demo, the founders of Secludy will demonstrate how their system utilizes Milvus to store and manipulate embeddings for generating privacy-protected synthetic data. Their approach not only maintains the confidentiality of the original data but also enhances the utility and scalability of LLMs under privacy constraints. Attendees, including machine learning engineers, data scientists, and data managers, will witness first-hand how Secludy's integration with Milvus empowers organizations to harness the power of LLMs securely and efficiently.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
zkStudyClub - LatticeFold: A Lattice-based Folding Scheme and its Application...Alex Pruden
Folding is a recent technique for building efficient recursive SNARKs. Several elegant folding protocols have been proposed, such as Nova, Supernova, Hypernova, Protostar, and others. However, all of them rely on an additively homomorphic commitment scheme based on discrete log, and are therefore not post-quantum secure. In this work we present LatticeFold, the first lattice-based folding protocol based on the Module SIS problem. This folding protocol naturally leads to an efficient recursive lattice-based SNARK and an efficient PCD scheme. LatticeFold supports folding low-degree relations, such as R1CS, as well as high-degree relations, such as CCS. The key challenge is to construct a secure folding protocol that works with the Ajtai commitment scheme. The difficulty, is ensuring that extracted witnesses are low norm through many rounds of folding. We present a novel technique using the sumcheck protocol to ensure that extracted witnesses are always low norm no matter how many rounds of folding are used. Our evaluation of the final proof system suggests that it is as performant as Hypernova, while providing post-quantum security.
Paper Link: https://eprint.iacr.org/2024/257
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
What is an RPA CoE? Session 1 – CoE VisionDianaGray10
In the first session, we will review the organization's vision and how this has an impact on the COE Structure.
Topics covered:
• The role of a steering committee
• How do the organization’s priorities determine CoE Structure?
Speaker:
Chris Bolin, Senior Intelligent Automation Architect Anika Systems
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
Dandelion Hashtable: beyond billion requests per second on a commodity serverAntonios Katsarakis
This slide deck presents DLHT, a concurrent in-memory hashtable. Despite efforts to optimize hashtables, that go as far as sacrificing core functionality, state-of-the-art designs still incur multiple memory accesses per request and block request processing in three cases. First, most hashtables block while waiting for data to be retrieved from memory. Second, open-addressing designs, which represent the current state-of-the-art, either cannot free index slots on deletes or must block all requests to do so. Third, index resizes block every request until all objects are copied to the new index. Defying folklore wisdom, DLHT forgoes open-addressing and adopts a fully-featured and memory-aware closed-addressing design based on bounded cache-line-chaining. This design offers lock-free index operations and deletes that free slots instantly, (2) completes most requests with a single memory access, (3) utilizes software prefetching to hide memory latencies, and (4) employs a novel non-blocking and parallel resizing. In a commodity server and a memory-resident workload, DLHT surpasses 1.6B requests per second and provides 3.5x (12x) the throughput of the state-of-the-art closed-addressing (open-addressing) resizable hashtable on Gets (Deletes).
Dandelion Hashtable: beyond billion requests per second on a commodity server
Saltzman.john
1. Systems Engineering Approach for
the Orion Pad Abort-1 Flight Test
John Saltzman
NASA Dryden Flight Research Center
February 10, 2011
Page 1
Used with Permission
2. Outline
• PA-1 Introduction (short video)
• PA-1 Roles & Responsibilities & System Providers
• Gathering inputs from Parent Stakeholders
• Organizing the project to build the system – (project-centric culture)
• Project Structure used to cross communicate
• Defining the system architecture & requirements
• PA-1 Lifecycle approach
•Verification approach
• Conclusions
NOTE: Lessons learned embedded throughout presentation
Page 2
3. Presentation Context
• Slides also intended to serve as a future use reference
• Slides will tend to have more stand-alone wording
• Will not delve into specific SE data base tools, Config. Mgmt. processes, etc…
• PA-1 Project did have Config. Mgmt. process, Risk Mgmt. processes, problem reporting
process, data base tool (for requirements traceability & verification tracking),
• Focus more on basic approaches & lessons learned rather than specific process & tools
• Made approach & lessons learned more generalized - apply to most SE challenges
• Address the human element in implementing a SE approach across a project
Page 3
4. Lamborghini
• 0 to 60 mph in 3.8 sec
• 0 to 100 mph in 8.6 sec
• 631 horsepower
5. Orion Launch
Abort System
Launch
Abort
System • 0 to 60 mph in 0.28 sec
• 0 to 100 mph in 0.42 sec
• 500,000 lb thrust
Crew • > 16g for 3 seconds
Module
Separation Ring
(SepRing)
6. Insert Pad Abort – 1 launch video here!!!
• From: www.vimeo.com/11631855
7. PA-1 Project-Wide Roles & Responsibilities
(spanned across 4 time zones)
Lockheed Martin (Prime Contractor)
• Crew Module Avionics
• Electrical Ground Support Equip.
• Mechanical Ground Support Equip.
Orbital (sub to LM)
• Launch Abort System
Langley Research Center
• Crew Module Primary Struct.
• Sep. Ring Primary Structure
Dryden Flight Research Center
• Flight Test Article Integration & checkout • Ground Support Equipment
• Systems Engineering Lead *
• Ground & Flight Operations
• Developmental Flight Instrumentation Johnson Space Center
• Flight Test Office Mgmt. Lead
• Ground Support Equipment
• Crew Module Parachutes
Page 7
11. Gathering inputs from ALL the Customer Stakeholders
(What we learned on PA-1)
Need good representation from your primary customer & system
stakeholders early in your lifecycle.
• Besides the primary customer, get inputs from other system stakeholders
• Anyone than can drive your system requirements
• i.e. Orion project, Launch site safety, missile treaties, standards, etc…
Gathering all stakeholders can be more difficult than expected
• NASA stakeholders commonly spread out across multiple
centers, agencies & industry partners
• Cross-talk amongst system stakeholders may be hampered
• Need ‘community organizer’ approach to gather stakeholder inputs early
If Johnny-Come-Lately’s join the system stakeholder forum late:
• Risk of adding late driving reqts (additional work & schedule delays)
• Applies to both baselining project reqts & technical review entrance
/ exit criteria.
• May induce huge delays (& costs) if late inputs result in modifying a major
contract or redesigning.
Page 11
12. Finding out what the Customer Needs
(What we learned on PA-1)
Initial draft of Mission / Flight Objectives received from
customer were not mutually understandable.
• Could have been interpreted differently between the parties
(project & customer).
Assumed mutually understandable Mission / Flight Obj. would be
delivered the first time on a silver platter (not the case)
• Needed to broker some of their Orion production goals into a flight test realm
• Solution: We drafted what ‘we’ thought their needs were
• Then asked them to tell us where we were wrong.
Project & customer need to establish a technical rapport
• Was necessarily tedious & difficult to accomplish
• Lowered the risk of unknowingly talking past each other
• Avoided discovering disconnects later in the lifecycle
• Usually at integration… (too late)
Commonly understood reference point (Little Joe II) was used
to directly engage the customer in mutually understandable
~
Apollo
Orion
discussions for Mission / Flight Objectives.
Page 12
13. Organizing the Project to… Build the System
(What we learned on PA-1)
Two - Layers to the systems engineering challenge:
1. Definition, Development, Verification of the system under test
2. Definition and structure of the support organizations (the people)
• I was taught… The structure of the project needs to reflect your system
architecture.
• Dinesh Verma, Dean School of Systems & Enterprises @ Stevens Inst. Of Tech.
• Gaps in project structure = gaps in system function & performance.
Expand on Challenge #2: Coordinate different groups at
multiple levels across different parts of the country
• Less of a purely technical effort
• More of an Engineering / project-based community organizing effort Project
technical community
organizing
Upcoming Slides to address Challenge #2:
• From: Fragmented Organizational-centric (NASA centers & contractors) cultures
• To: Single project-centric culture.
• SE personality type needed to engage communication across project teams
• Organizational structure reflecting the architecture… for PA-1 project
Page 13
14. From: Multiple Organizational Cultures
To: Single Project-centric culture
Culture
What we learned from PA-1…. ‘C’
Newly defined project roles & responsibilities, processes Culture
established across a large (multiple org.) project are not ‘A’ Culture Culture
instantaneously carried out in a perfect manner. ‘B’ ‘F’
Culture Culture
It takes some mutual pain (& more time than most like) to ‘E’
‘D’
transition: Non-integrated Center &
• From: Non-integrated Center & contractor set of cultures, to an… contractor cultures
• To: Integrated project-centric culture.
Need influential advocates (community organizers) from each
org working together.
• Key agents from each org advocate project-centric
culture, approach, processes back to their group.
Need a comprehensive approach / plan to define / develop /
test system as well as structure project.
• Each org buys into.
On PA-1: Became predominantly known as a project-centric Integrated project-
culture between PDR & CDR centric culture
• Biased opinion of presenter, not scientific assessment
Page 14
15. From: Multiple Organizational Cultures
To: Single Project-centric culture
What we learned from PA-1…. (Cont.)
Set up communication forums / hubs for technical cross talk
• Roll call & status from all discipline leads
Technical Meetings
Need team-wide collaborative web environment
• One place to find the latest document version & related info.
• Very helpful with coordinating & tracking verification
• Sometimes difficult to achieve
• Organizational web security standards
• Contractual / proprietary issues among project partners
Project & Team-wide meeting calendars were essential
• One reference point for team meetings.
Team social events away from PowerPoint venues were beneficial
Flight Test Office had direct control over most project teams….
• But only had ‘influence’ over some project teams
• Could not rely on direct (contractual) authority
• Rely even more on community organizing skills to engage
these groups and… the mgmt structure above them.
• Dedicate person within project to work directly with
‘influence-only’ partners. Page 15
16. From: Multiple Organizational Cultures
To: Single Project-centric culture
What we learned from PA-1…. (Cont.)
Watch out for the typical engineering drill-down mentality
• “I’ll focus on my part, you focus on yours…”
• Most engineers delight in avoiding the human interaction aspect of
engineering and desire to focus solely on the product itself.
• Reiterate: Engrs. need to think & talk across org. & system boundaries
Project communication gaps swarm around Lone Rangers
• Project Community Organizers need to spot & close these gaps
Assume cross-functional project communication will fail
at some point unless:
• Key disciplines across project are proactively & directly
engaged regularly… throughout lifecycle
• “Unless everyone who needs to know does know, ... somebody
somewhere will foul up”
• Eberhardt Rechtin, 1997, The Art of System Architecting
Page 16
17. From: Multiple Organizational Cultures
To: Single Project-centric culture
What we learned from PA-1…. (Cont.) “Houston, w
e have a
high five.”
Some PA-1 evidence of a project-centric culture:
Unsolicited comment from a Lockheed avionics engineer to a
NASA systems engineer (PA-1 post-flight ‘social’ event):
• “It would be a shame to break up this team… For example, whenever
I wanted, I could just pick up the phone and talk directly to the (LaRC)
structures lead to see how possible changes affect us both.”
Page 17
18. Valuable Systems Engineering traits when Organizing a Project
Systems Engineering / Community Organizer traits:
• Don’t necessarily have to be overly social
• However SE’ers need to:
• Engage a wide variety of personality types across the project
• Be very approachable
• Recognize communication gaps, for example:
• Only hear repeated concerns on only one side of the story / issue.
• No clear way for groups to engage each other
• Carry forward concerns / issues over communication barriers
• Be organized… beyond just yourself
• Also be an organizer
• Participate in regular forums that promote cross-talk
• Value added if above qualities apply to project leads as well.
• Others on the project can help organize, but….
• It’s the SE’s job to assure the organizational structure supports the architecture
Page 18
19. Valuable Systems Engineering traits when Organizing a Project
(continued)
When project leads are not a fan of NPR 7123.1a
• Don’t confront them as if you’re the NPR police…
• Win them over by asking, “How can we best make ‘_____’ clear to
others within the project?”
• This is how they can meet the intent of NPR 7123.1a …. w/o them
knowing it (sneaky…)
• In the background you can check off the NPR 7123.1a check-list
7123.1a
Some project leads may not fully understand Systems Engineering
• Help ghost-write their requirements if necessary
• This was done for 1 module and 1 subsystem on PA-1
Page 19
20. Project structure used to establish project-centric culture
(for PA-1)
Parent Org (Orion) Structure:
• ERB: Technical decisions
impacting parent org
• T&V Control Panel: Cost /
schedule decisions impacting
parent org.
FTO Org. Structure:
• ERT: Tech. decisions w/in FTO
• Flt. Test Panel: Cost / schedule
decisions w/in FTO
• 4 Module level IPT’s
• SEIT (5 branches)
1. Systems Eng.
2. Avionics (largest & most
complex subsystem)
Positions were discipline & deliverable specific, not center specific. 3. Operations
4. System Design
Can’t guarantee this is the best way to organize, but: 5. System Analysis
• It was clear and understandable to the team… which • Met every week
compensates for a lot.
Page 20
21. Defining the Architecture
• “If social cooperation is required, the way in which a system is
implemented and introduced must be an integral part of its
architecture.”
• Rechtin, E. “Systems Architecting, Creating & Building Complex Systems”
Page 21
22. Defining the Architecture (Cont.)
• Before we generated system requirements, we defined the architecture
Definition of
architecture helped:
• Define spec. tree
hierarchy
• Define requirement
allocation categories
• Define boundaries of
elements within system
• Next slide… looked at
system elements from
3-views
Page 22
23. Example of 3-View Architecture Definition for Crew Module
(This approach was used across the system)
Interface View Took global perspective of
system elements:
• Functional View
• Dev. & Op. Phases
• Functional Modes
• Sample slides shown
• Interface View
• External Interfaces
• Sample slides shown
• Physical View
• High Level Physical
Attributes
• More detailed
attributes
(weight, C.G., Moments
of Inertia, OML) in a
separate Geometry &
Mass Properties doc.
• No sample slide
Page 23
25. Actual ‘Phase’ Chart shown @ PA-1 SRR (Cont.)
(From Functional View)
Many projects do not go through individual
requirements at their SRR (is it really an SRR then?):
• Time constraints are understandable, but:
• Example above is proof it’s possible to review
Page 25
requirements at a ‘paraphrased’ level at SRR.
26. Actual ‘Functional Mode’ Chart shown @ PA-1 SRR
(From Functional View)
• Paraphrased versions of
the requirements were
used to walk reviewers thru
the requirements at SRR in
an expedient manner.
Page 26
27. Actual ‘External Interface’ Chart shown @ PA-1 SRR
(From Interface View)
• Used to get stakeholder agreement on external interface types
Page 27
28. Actual ‘External Interface’ Chart shown @ PA-1 SRR (Cont.)
(From Interface View)
• Paraphrased versions of the requirements were used to walk
reviewers thru the requirements at SRR in an expedient manner. Page 28
29. Top Tier of PA-1 Spec Tree
(For Reference)
Page 29
30. Defined System & Instrumentation
Sensors in a parallel manner
Mission Objectives drove Flight Objectives Drove Master
the system-wide design Measurement List for the sensors
Mission Objective: Mission & Flight Flt. Objective: Determine stability char. of
…demonstrate Objectives LAS+CM configuration during a pad abort
satisfactory perf. &
operation of the LAS. • Measure Of Performance (MOP):
• Evaluate LAV attitude (including flight path
angle, ψ, θ, φ)
Standard • Evaluation Criteria:
System
allocation to • LAV dynamics compared to 6-DOF
Requirements
lower level Data Analysis simulation, adjusting for day-of-flight
Document
requirements Plan conditions
• Required Parameters:
Module A • LAV
position, velocity, acceleration, attitude, angu
Module B
lar rates, angle of attack, sideslip, estimated
Module C
thrust from abort motor, day-of-flight
winds, and atmospheric conditions derived
from on-board measurements.
Subsystem A Master
Subsystem B Measurement • LS041V: Z-axis acceleration ….
List (MML) • LS0….
Subsystem C
Page 30
31. Pad Abort 1 Review Lifecycle
• “Before proceeding too far, pause & reflect! Cool
off periodically and seek an independent review”
• Douglas R. King, 1991
• “If you think your design is perfect, it’s only
because you haven’t shown it to someone else.”
• Harry Hillaker, 1993
Page 31
32. Pad Abort 1 Review Lifecycle (Cont.)
STTR*:
Primary
Structure
PTR: Periodic Technical Review
FTTR: Flight Test Readiness Review
STTR: Subsystem Table Top Review
*: Discussed further on next page
Page 32
33. Pad Abort 1 Review Lifecycle (Cont.)
(What we learned on PA-1)
Technical Review Entrance / Exit criteria tailored from NPR 7123.1a
Appendix G
• Approved by customer well before each review
• Resulted in mutually clear expectations for each review early-on
Early coordination with customer helped achieved timely buy-off
of review approach
• Increased likelihood of reviews meeting customer expectations
• Without early coordination: Increase risk of surprising customers at the
review (“… can’t proceed to the next phase until…. you do A, B, C, etc…”)
• WARNING: Customer may still change their mind on review criteria
• But, baseline criteria will help justify impacts
STTR approach used to approve procurement & basic design of CM
Primary Structure before PDR (yes, I said PDR).
• Used only if:
• Risk of expediting project is lower than the schedule risk of waiting Build
Wait
for the review early after
• Have a well established risk mgmt system to track / update risk CDR
mitigations (i.e. workable retro-fits for increased loads from
downstream analysis). Risk scale Page 33
34. Pad Abort 1 Review Lifecycle (Cont.)
(What we learned on PA-1)
Entrance / Exit criteria used to define presentation template for to
each subsystem at each technical review.
• Provided consistency for each subsystem presentation comparison across system
• Made it easier to define subsystem readiness gaps (issues) & go fwd plans
• Reduces chance of overlooking something important across system
Go forward plan
Tailoring of entrance / exit criteria was / is key:
• I was taught… Strictly following a text book approach for systems engineering on a
project would practically guarantee failure.
• Dinesh Verma, Dean School of Systems & Enterprises @ Stevens Inst. Of Tech
• Do NOT deny engineering judgment from past pain
Examples of ‘tailored’ subsystem presentation templates shown on next 2 slides for PDR. Page 34
35. Example of Subsystem presentation
outline / template for PDR (PTR-2)
• Entrance Criteria – tailored from NPR 7123.1a for your subsystem
• Schedule – Subset of the master schedule for your particular subsystem / deliverables
• Document/s Status – Self explanatory
• Driving Requirements – Shows requirements that are causing your design to be ‘what it is.’
• Safety – Hazards pertaining to your particular subsystem
• External Interfaces – Summary of interfaces external to your subsystem
• Design Concept – Block diagrams, Sketches, Drawing trees, Analysis
• T&V Approach – Basic description of Test approach and how requirements will be verified.
• Issues & Resolutions – Identify open issues and a plan on how they will be resolved.
• Go Forward Plan – Path to CDR
• Exit Criteria – tailored from NPR 7123.1a for your subsystem
- Resulted in reviewers knowing expected topics for each subsystem.
- Enabled reviewers to consistently compare subsystem readiness across the system.
- Made it easier for project to pro-actively define go-forward plans for subsystem ‘issues’
Page 35
36. Example of Subsystem Entrance / Exit
Criteria template for PDR (PTR-2)
• Consistently showed reviewers ‘how’ each
PTR-2 Subsystem Level Entry Criteria Slide subsystem met its share of the system-wide
Preliminary subsystem specs for each H/W & S/W CI entrance / exit criteria.
Draft Subsystem Interface Requirements Docs • If template not used… could result in
inconsistent coverage from subsystem to
Draft Interface Control Documents
subsystem.
Design / Analysis Documentation • Reviewers may conclude project
Engineering Drawing Trees coordination is inconsistent
T&V Planning • Warning flags go up
PTR-2 Subsystem Exit Criteria Evidence Slide
Subsystem requirements defined & trace to parents & • Driving Requirements show traceability
are allocated to components & external subsystems • Requirement allocations are in specs
Subsystem Level designs exist and are consistent • Design spec complete with ___ TBD/Rs
with their corresponding requirements set • Design drawings ___% complete
Subsystem interfaces identified and are consistent • IRD / ICD’s with ___ TBDs / TBRs
with their corresponding subsystem design maturity
Project risks identified & mitigation strategies defined Project risk #’s in IRMA risk database
T&V approach is adequate to proceed Verification methods identified & test
S&MA adequately addressed in the preliminary Hazard report #’s & referenced S&MA
design & the preliminary design-based S&MA analysis
requirements & approach have been approved Page 36
37. Verification
(What we learned from PA-1)
Early-on:
• Believed defining & implementing workable requirements would be the greater challenge
• Foregone conclusion that the easier task would be to record the verification of those same
requirements later in the lifecycle. (WRONG)
Looking-back:
• Experience taught us:
• No tasks can realistically be categorized as significantly easier through lifecycle
• Complexity of coordinating the human element of requirements verification
comparable to human element challenge of implementing those same requirements
earlier in the lifecycle.
• i.e. Coordinating latest versions of test results & analysis at each associated level
while briefing burn-down status
• Next slide touches on contributors to this challenge
Page 37
38. Verification Planning
(What we learned from PA-1)
Requirements & Integration &
Development activities Verification Activities
System Verification planning activities
Level
Module
Level
Subsystem
Level
Component Level
Development …. & Integration
Verification Planning Activities:
• Strong correlation within module &
subsystem verification efforts
• Gaps in correlating Module & Subsystem
verifications with System level verif. activities
• Leads busy implementing requirements & Lesson Learned:
design early in lifecycle • Where ever possible: Complete system verification planning
• Less time to tie all levels in system efforts with module & subsystem leads earlier in the lifecycle
verification planning • Set up more direct ‘check-list’ of tasks to reduce avoidable
• Made for more work later in the lifecycle to system-wide review & analysis later in the lifecycle
correlate latest (under the gun). Page 38
39. Actual PA-1 Subsystem Verification Chart briefed to Mgmt.
What we learned from PA-1...
Most subsystem verifications were more straight fwd
compared to module & system level verifications
• Module / System: more integrated analysis / test results).
Some subsystem & module requirements were held
in verification ‘purgatory’ (incrementally verified
multiple times as integration scope expanded)
Subsystem / module reqt verification sent to
heaven when final integrated
verification activity was completed.
Page 39
40. Actual PA-1 Module Level Verification Status Chart briefed to Mgmt.
What we learned from PA-1…
Two kinds of module level verifications:
1. Purely a subsystem child roll-up
• i.e. environmental requirements
2. Child roll-up with some form of integrated analysis:
• More paperwork used here to tie-in all combination
of integrated analysis and test results.
• Use community organizing skills to assure module,
subsystem, analysis & integration leads are talking.
Page 40
41. Actual Module Reqts. Burn-down Chart Briefed to Mgmt.
What we learned from PA-1…
Range of
mgmt
feedback if
project is
ahead or
behind the
verification Constructive
Joy burn-down feedback…
Page 41
42. Actual System Reqts Verification Burndown briefed to Mgmt.
• System Level Burn-down was more of a gradual slope
• Factored in a buffer turn-around time for completion of
paperwork after successful verification (A, T, I, D) activities.
If you’re behind the burn-down profile...
• Have a credible story for mgmt on how you’ll still meet flt. date
• Example: “Of the 11 reqts above the burn-down, 10 were
successfully tested, but are awaiting final approval our project review
board, which is tomorrow.”
Page 42
43. Conclusions & Perspectives Gained
• Get engaged early with ALL of your parent stakeholders – Establish technical rapport
• Importance of looking at organic parts of the project supporting the system.
• i.e. Project organization, processes, various disciplines, human nature
• Needs to be worked in parallel with defining the system
• Reflects the architecture
• The more clear things can be made within the team, the more achievable a project-
centric culture will be.
• Single reference points for (defined preferably in a collaborative web environment):
• Project & Team meetings (with charters)
• Technical & Project decision process - For decisions affecting project or technical baselines
• Schedule
• Organizational structure & roles / responsibilities
• Risk Mgmt
• Configuration Mgmt
• Problem reporting & resolution
• Technical Review approach & entrance / exit criteria
• Key project & engineering documents
• Verification Planning
• To get a large group of individuals in different orgs across the country to develop a
cohesive system…
• Takes more than a sound SE approach
• It also requires a human interaction mindset that is not intuitive to most engineers. Page 43
44. Conclusions & Perspectives Gained (cont.)
• Get stakeholder buy-in of architecture definition before deriving system requirements
• Derive system requirements from architecture definition.
• Have a template for subsystem presenters at technical reviews tailored from NPR
7123.1a entrance / exit criteria
• Verification coordination will sneak up on you if not thoroughly completed early-on
• Correlate Module & Subsystem verifications with System level verification activities early-on
• Reduces frantic scrambling around later in the lifecycle
Side Notes:
• PA-1 project passed 2010 NASA OCE Systems Engineering audit
• 2011 NASA Systems Engineering (SE) Excellence awarded to the Orion Pad Abort-1 SE Team
Page 44
45. Conclusions & Perspectives Gained (Cont.)
Systems Engineer Triangle
Invaluable
Systems
Engineer
Skill-set
Community Organizer Mindset
(Assure org reflects the architecture)
Page 45