Formal Information-Based Standards for Test and Diagnosis John W. Sheppard, Co-Chair Mark Kaufman, Co-Chair Diagnostic & Maintenance Control IEEE SCC20.

Slides:



Advertisements
Similar presentations
Systems Engineering From a Life Cycle Perspective John Groenenboom Director Engineering – Mesa Boeing Rotorcraft Dec 12, 2007.
Advertisements

Enterprise Grants Management The Time is Right. Transformation From To.
1 INCOSE Chesapeake Chapter Enterprise SE Panel Discussion L. Mark Walker/LMC 21 March 2007.
ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
OASIS Reference Model for Service Oriented Architecture 1.0
Object-Oriented Analysis and Design
SAK5102 SOFTWARE EVALUATION Semester II 2008/ credits Tuesday 6.30 pm – 9.30 pm (BK1) Assoc. Prof Dr. Abdul Azim Abd Ghani 1.
Introduction and Overview “the grid” – a proposed distributed computing infrastructure for advanced science and engineering. Purpose: grid concept is motivated.
SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context.
1/31 CS 426 Senior Projects Chapter 1: What is UML? Chapter 2: What is UP? [Arlow and Neustadt, 2005] January 22, 2009.
Iterative development and The Unified process
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
EADS TEST & SERVICES TS/EL/T N°08_04/08 Page 1© Copyright EADS TEST & SERVICES 2008 Engineering Process for Systems Testability Analysis. Presentation.
Enterprise Architecture
What is UML? What is UP? [Arlow and Neustadt, 2005] January 23, 2014
UML - Development Process 1 Software Development Process Using UML (2)
Reuse Standards Dr. Carma McClure Extended Intelligence, Inc. Copyright (c) 1998 by Extended Intelligence, Inc.
TDT4252/DT8802 Exam 2013 Guidelines to answers
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Knowledge representation
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
1 Software Quality CIS 375 Bruce R. Maxim UM-Dearborn.
Service-enabling Legacy Applications for the GENIE Project Sofia Panagiotidi, Jeremy Cohen, John Darlington, Marko Krznarić and Eleftheria Katsiri.
Introduction to MDA (Model Driven Architecture) CYT.
Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.
Page 1 Designing for Health; A Methodology for Integrated Diagnostics/Prognostics Raymond Beshears Raytheon 2501 W. University McKinney, TX
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
TitleIEEE Standard for Mostly RESTful Orchestration Interface Protocol (mREST) for Orchestrating Software-Controlled Assets via Web Services ScopeThe mREST.
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard CS SAB Meeting November.
Lecture 7: Requirements Engineering
1 Introduction to Software Engineering Lecture 1.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
W HAT IS I NTEROPERABILITY ? ( AND HOW DO WE MEASURE IT ?) INSPIRE Conference 2011 Edinburgh, UK.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Chapter 3: Software Project Management Metrics
ANKITHA CHOWDARY GARAPATI
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Introduction to Measurement. According to Lord Kelvin “When you can measure what you are speaking about and express it in numbers, you know something.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
1 Chapter 8 Building the Analysis Model (1) Analysis Concepts and Principles.
Standards Coordinating Committee 20 on Test and Diagnosis for Electronic Systems Slide 1 SCC20 Liaison Report Dr. John W. Sheppard May
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Software Engineering Introduction.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Software Engineering Lecture 10: System Engineering.
Course: Software Engineering – Design I IntroductionSlide Number 1 What is a specification Description of a (computer) system, which:  is precise;  defines.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013.
1 Software Requirements Descriptions and specifications of a system.
1 The XMSF Profile Overlay to the FEDEP Dr. Katherine L. Morse, SAIC Mr. Robert Lutz, JHU APL
SQA project process standards IEEE software engineering standards
Discussion Topics for Exploring OMG UPDM Way-ahead
Software Quality Control and Quality Assurance: Introduction
ISO/IEC JTC 1/SC 7 Working Group 42 - Architecture Johan Bendz
SQA project process standards IEEE software engineering standards
Identify the Risk of Not Doing BA
The Systems Engineering Context
Wizard Templates.
IEEE Std 1074: Standard for Software Lifecycle
Software Requirements
September 14, 2010 Mukund Modi NAVAIR Kevin Masur Joe Stanco
Enterprise Data Model Enterprise Architecture approach Insights on application for through-life collaboration 2018 – E. Jesson.
Measurement What is it and why do it? 2/23/2019
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Presentation transcript:

Formal Information-Based Standards for Test and Diagnosis John W. Sheppard, Co-Chair Mark Kaufman, Co-Chair Diagnostic & Maintenance Control IEEE SCC20

System Complexity Modern systems and products are complex. Test systems required to support products are equally complex. Managing complexity involves: –Controlling risk and cost. –Intelligent distribution of resources. –Management and integration of information from these distributed sources. –Definition of unambiguous information requirements through a common language.

Requirement Interdependence Testability requirements are based on system specifications. –Testability metrics not precisely defined or have multiple definitions. –Existing tools/methods calculate metrics differently. –Metric ambiguity is driven by existing guidelines (e.g., MIL HDBK 2165): Test requirements are established to satisfy testability goals. –Often tied to ATS architecture. No standard way to specify test requirements. Therefore …

DMC Scope Effective management of test and maintenance information is critical. –The test and maintenance engineering process is, by nature, highly distributed. –The information requirements to support test and maintenance engineering are highly diverse. DMC standards focus on reducing the cost and risk of managing the information required for test and maintenance.

The Focus Communication!!! Communication requires prior agreement on the characteristics of the message. –Structure –Content In test and diagnosis, this equals information exchange among and between test assets and maintenance organizations.

Information-Based Architecture Communications Backbone Diagnostic System Test System Historical Data System Under Test Application Executive

An Information-Based Approach Information Framework IDEF0 (Activity Models) IDEF1x (Data Models) EXPRESS (Information Models) diagnose repair fault BIT Codes TOs Define Test & Diagnostic Process Capture Required Information Implement Information System

Information Model Definition: An information model is a formal description of types (classes) of ideas, facts, and processes that together represent of a portion of interest of the real world. Purpose: To identify clearly the objects in a domain of interest to enable precise communication about that domain. Components: objects or entities, relationships, constraints. Outcome: Unambiguous exchange of information between systems.

Integrating Test & Diagnostic Information Test & Diagnostic Information Framework Test & Diagnostic Data Diagnostic Data Test Data Product Data History Data P1598 TeRM P1232 AI-ESTATE P1522 Testability Pxxxx SIMICA

The Standards IEEE P1232Standard for Artificial Intelligence Exchange and Service Tie to All Test Environments (AI-ESTATE). IEEE P1522Standard Testability and Diagnosability Characteristics and Metrics. IEEE PxxxxStandard Interface for Maintenance Information Collection and Analysis (SIMICA). IEEE P1598Standard for the Test Requirements Model (TeRM)

IEEE P1232AI-ESTATE P1232 Define information for system test and diagnosis. Exchange diagnostic information between applications. Support modular diagnostic architectures. Support interoperability with other test assets. Define information for system test and diagnosis. Exchange diagnostic information between applications. Support modular diagnostic architectures. Support interoperability with other test assets.

IEEE P1522Testability/Diagnosability P1232 P1522 Define fundamental information for testability analysis. Tie definitions to standard modelseliminate ambiguity. Derive metrics and characteristics based on fundamentals. Provide foundation for extension and expansion. Define fundamental information for testability analysis. Tie definitions to standard modelseliminate ambiguity. Derive metrics and characteristics based on fundamentals. Provide foundation for extension and expansion.

IEEE PxxxxSIMICA P1232 P1522Pxxxx Define information domain of system maintenance. Support capture of historical maintenance/diagnostic data. Facilitate discovery/extraction of maintenance knowledge. Provide foundation for diagnostic and product maturation. Define information domain of system maintenance. Support capture of historical maintenance/diagnostic data. Facilitate discovery/extraction of maintenance knowledge. Provide foundation for diagnostic and product maturation.

IEEE P1598TeRM P1232 P1522Pxxxx P1598 Provide formal description of product behavior under test. Define formal semantics for test requirements. Feed entire product lifecycle (concept to field) Emphasize what to test, not how to test. Provide formal description of product behavior under test. Define formal semantics for test requirements. Feed entire product lifecycle (concept to field) Emphasize what to test, not how to test.

Risk Reduction Optimizes use of test equipment/ resources and maintenance information to maximize availability. Promotes test effectiveness through requirements-driven test engineering. Provides means to develop strategy for test and diagnostic effectiveness assessment (testability and diagnosability). Facilitates unambiguous testability prediction and validation to ensure weapon system support specification compliance. Promotes cost-effective development and integration of state-of-the-art COTS products into ATS. Promotes flexibility in diagnostic architectures through separation of data and process.

Life Cycle Cost Reduction Supports advanced diagnostic technologies to improve product maintenance. –Helps to find bad actors and target maintenance problems. Provides a foundation for integrating test assets with other RMT analysis tools and methods. –Supports trade-off and competition among COTS tools to reduce ATS development cost. –Facilitates integration with related standards efforts (e.g., PLCS) to broaden resource base. Provides foundation for closed-loop corrective action analysis. –Supports diagnostic process improvement/maturation to reduce field test and maintenance cost and maximize availability.

Industry Interest/Involvement Committee Membership –Industry (ARINC, Boeing, Honeywell) –Tool Developers (DSI, QSI, HSI) –US DoD (All services) –Academia (Vanderbilt, NPG, U Conn) Industry Interest –OSA-CBM –PLCS/STEP –NASA –NxTest

Call for Participation We are looking for help: –Provide technical support and participation in the committees work. –Promote objectives of the standards in service organizations. –Promote objectives of the standards with contractors. –Incorporate DMC standards in AMB initiatives (e.g., NxTest).

Contact Information Dr. John Sheppard, ARINC – Mark Kaufman, NSWC, Corona Division –