# Presentation: 772334

## Paul KellerECS L4 Lead31 Mar 2004

***Digital Shuttle***

***VIB Workshop******March 2004***

## Shuttle Information Lifecycle Challenges

***Shuttle Information Lifecycle Challenges***

- Shuttle Program has many heterogeneous data sources
- Difficult to navigate, integrate, synchronize, numerous legacy systems
- Organizationally and geographically-dispersed workgroups compartmentalize work efforts
- SSPO requested initial focus on specific problem areas
- Engr drawings with engineering orders (EO)
- As-Designed vs. As-Built discrepancies
**Lack of common framework to model/organize knowledge and represent/integrate lifecycle risks**
- Gathering input from NASA and SFOC contractors will provide shared models representing agreed meanings about aspects of the SSP in precise ways

## Digital ShuttleAs-Designed drawing conversion

- <CAD_DOCS>
-   <DOC_SET>
-     <DRAWING>
-       <PAGE>1 of 1</PAGE>
-           <TITLE_BLOCK>
-              <PART_DESCRIPTION>
-                   <PART_NAME>SPACER-CLOSEOUT FRAME</PART_NAME>
-                   <PART_NUMBER>V070-334150</PART_NUMBER>
-                    <CODE_ID>03953</CODE_ID>
-                    <SIZE>D</SIZE>
-                    <SCALE>4/1</SCALE>
-              </PART_DESCRIPTION>
-              <APPROVALS>
-                  <TYPE>
-                      <VALUE>DRAWN BY</VALUE>
-                      <NAME>E. CRESEE</NAME>
-                      <DATE>01-13-75</DATE>
-                  </TYPE>

- Convert Orbiter drawings, incorporating EOs, into 3-D CAD models with intelligent metadata
- Capturing non-geometric information into XML / RDF files
- Incorporate into Shuttle Ontology
- Provides accurate engineering models for visualization (simulation) and engineering analysis (structural, thermal, kinematic, mass properties, etc.)
**RTF: Forms basis for SSPO response to CAIB Recommendation R10.3-2**

## As-Designed Drawing ConversionDefine drawing vocabulary – XML, RDFS

_**Engineering and Manufacturing Data (30%)**_
- Title Block Data:
- Part Name and Desc.
- General Tolerances
- Parts List Data:
- Quantity
- Material
- Data Specifications
- Manufacturing Data
- General Notes
- Engineering Orders
- Feature Notes
- Supplemental Notes

_**Planning Data (70%)**_
- Application Data:
- Next Assembly
- Used On
- End Item
- Application Quantity
- Mod Codes
- Planning note ( may be made from)
- Mod kit DWG references

## Digital ShuttleAs-Built / As-Maintained Digital Modeling

- Scan Orbiter to create accurate as-built 3-D models
- Method for virtual assembly and digital mock-up, resolve as-design differences, location identification, process planning, analysis
**RTF: Scanning and modeling Orbiter TPS to provide de-facto reference geometry for on-orbit TPS health evaluation**

## Digital ShuttleCAIB support

***Digital Shuttle******CAIB support***

**Scanned Left Wing Leading Edge Debris Located in 3D overlaid with as-designed part and loft data**

**Combine Left Side Orbiter OML 3D Model**

## Digital ShuttleCAIB support

- Digital modeling for virtual reconstruction
- Example of lower left wheel well area debris located on virtual model

**Perform 3D scans of debris from SLF grid**

**Locate scanned piece in 3D model using X,Y,Z coordinates from current as-designed engineering data**

## Engineering KM issues in SSP

- Need broader approach for modeling to achieve a model-based world – how do we imbue Systems Thinking?
- Especially important when we want to introduce systemic changes like new focuses on integrating Risk (awareness, modeling, decision support)
- Corporate knowledge loss is pervasive
- Too much tacit, turning all into explicit requires enormous effort
- Dire need to introduce minimally intrusive “work as modeling” tools and methods to capture daily work
- choice capture, lessons learned, risk characterization throughout lifecycle
- Denote information in a machine intelligible form (actionable)
- Organizational learning
- How can does my process/work/decision affect the program, at a granular or macro level?
- Where has something similar been done before, what were all the factors, constraints, solution sets considered?
- Complexity management = abstraction management
- Need better tools and approaches
- Semantic interoperability remains a key goal

## SSP Ontology modelingOrganizational Challenges

- Highly distributed workforce
- Extremely stratified both geographically and organizationally
- Compartmentalized
- Good
- A given domain may be relatively small and well-defined, many boundaries established via processes and artifacts
- Bad
- Inconsistent overlap with larger enterprise domains, much work needed in mapping vocabulary and concepts both to enterprise domains and with peer domains
- Nobody is a trained “knowledge modeler”
- Many of the concepts of ontology modeling are too abstract for many SMEs
- These end users cannot be expected to understand subtle modeling differences, impact of modeling decisions (i.e., where and when to use reification)

## Ontology modeling - approach

- Embrace the W3C Semantic Web capability for distributed authoring
- Support both “Program-sanctioned” and individual versions
- Provide a variety of simplified techniques for authoring
- Allowing annotations are key
- While we would prefer a Word document (report, instruction, procedure, etc.) to be fully converted into RDF triples, we also want to encourage the creation of intelligent metadata
- Strict adherence to W3C standards
- XML, XML-Schema, RDF, RDFS, OWL-Full
- However, at current state of the standards, and compliant triplestore products, all our modeling needs are not addressed
- Top-level ontological domains defined
- Enterprise, Social, Process, Task, Device, Domain
- Association superclasses defined

## W3C Semantic Web Stack

**Notes:**
The Rules layer is where a user can express relations between data that are beyond any OWL-style language.  For this reason, a great deal of inferencing is reserved for the rules layer.  But at the rules layer, none of the DL guarantees hold.  This places a severe limit on the advantages of having a tractable, decidable layer in such a system, since overall system performance is just as unpredictable as it is for any program.
It is important to note here that a commitment to DL-reasoner carries certain implications for modeling. Specifically, axioms must be expressed using class and subclass structures as opposed to rules.

## Ontology ModelingSystems Thinking

- Aspects of IEEE 1471 (SW Architecture Representations)
- Enterprise
- Describes the purpose, policies, organization of the SSP
- Information
- Describes how information for system components and elements is produced and consumed
- Technology
- Describes how components are dependent on specific technologies (per discipline; mechanical, electrical, thermal, hydraulics, software, etc.)
- Lifecycle
- Considers the systems in terms of work products produced, engineering methods, best practices for processes

## Ontology Modeling Lifecycle Views

- ISO 15288 (System Lifecycle Processes)
- Common framework for describing the life cycle of systems with complete set of well-defined processes and associated terminology
- Provides for the definition, control, and, improvement of the lifecycle processes
- Concept formulation
- Requirements
- Design
- Implementation (Production/Engineering)
- Operation
- Decommission

## Enterprise Viewpoint (Governance)
Form: Stakeholder Participation Map
Information Viewpoint
Form: Work Product Information Map
Technology Viewpoint
Form: Vehicle Element
Includes sub-domains
Structure, Electrical, Hydraulic, Thermal, ...
Form: Shuttle Element Technology Map
Lifecycle Viewpoint
Form: Task Map
Disgruntled worker viewpoint
Form: Feedback

- Form: Stakeholder Participation Map
- Information Viewpoint
- Form: Work Product Information Map
- Technology Viewpoint
- Form: Vehicle Element
- Includes sub-domains
- Structure, Electrical, Hydraulic, Thermal, ...
- Form: Shuttle Element Technology Map
- Lifecycle Viewpoint
- Form: Task Map
- Disgruntled worker viewpoint
- Form: Feedback

***Organic ontology modeling******lowest common denominator: forms***

## Organic ontology modelingSample Form

| Template 1: Stakeholder Participation Map |  |
| --- | --- |
| Role Definition |  |
| Name | Person’s name |
| Role | Designated Job Role. Examples are “Chief Engineer”, “Deputy Director”, “Director”, Division PM”, “Documentation Support Assistant”, “Lead System Engineer”, “Logistics Engineering Lead”, and “Upgrades and Infrastructure Manager”. |
| Organization | Name of the organization that the person belongs to.  Examples are “United Space Alliance”, “Boeing”, “NASA Ames “, “NASA KSC”, “NASA JSC”. |
| Primary Work Location | Name of the organization that the person primarily work at.  Examples are “NASA KSC”, “NASA JSC”, “USA”, “Boeing”. |
| Division | Unit within the designated organization. Examples of divisions within NASA are “Electrical Systems Division”, “Engineering Integration”, “Fluid Systems Division”, “Ground Systems Division”, Mechanical Systems Division”, “Safety and Mission Assurance Division” and “Shuttle Logistics Division”.  An example within SFOC is FSSO. |
| Project Office | The project office that you may be involved with. Examples of project offices are “External Tank Project Office”, “EVA Project Office, “Space Shuttle Main Engine Project Office” and “Space Shuttle Projects Office”.  |
| Program Elements | The activity areas of SSP that the stakeholder is involved with. Examples of elements include: “Space Shuttle Customer and Flight Integration”, “Space Shuttle KSC Integration”, “Space Shuttle Management Integration”, “Space Shuttle Payload Processing”, Space Shuttle Systems Integration” and “Space Shuttle Vehicle Engineering”. |
| Program Functions | A list of the program functions performed for each of the program elements. For each program function, a list of the specific concerns being addressed should be described. For example, to validate design assumptions, to determine in-family compliance, to check design against requirements. |
| Obligations |  |
| Production Obligations | For each of the program functions, a list of the work-products that the stakeholder is responsible for producing. |
| Approval Obligations | For each of the program functions, a list of the work-products that the stakeholder approves. As an example, two of the work-products that the “Division PM of SR&QA” approves are the “JSC Flight Equipment Acceptance”, and the “GFE Certification of Flight and Launch Readiness”. |
| Concurrence Obligations | For each of the program functions, a list of the work-products for which the stakeholder needs to give his or her sign-off. |
| Review Obligations | For each of the program functions, a list of the work-products that the stakeholder is obliged to review. |
| Standard Operating Procedures | For each of the program functions, a list of NASA and other reference documents that the stakeholder needs to perform work. These procedures and guidelines are for the creation, modification, review and approval of the work product(s). Many of these guidelines are captured in the Product Development Plans (PDPs). The metadata will reference relevant PDP sections. |
| Communication and Collaboration |  |
| Collaborators | For each of the program functions, a list of the parties with whom the stakeholder conducts collaboration. |
| Information Interests | For each of the program functions, a list of the work-products that the stakeholder is interesting in receiving. |
| Reference Materials |  |
| Supporting Documents | Use this field to upload any supporting documentation that would assist in defining this template.  At a minimum, upload sample documents (or system screenshot if appropriate) that are identified in the responses to the above fields.  Examples would include (but are mot limited to) organizational charts, plans (ex., PDP), breakdown structures (organization, work, product, system), work documents (ex., WAD), screenshots of applications, standard operating procedures, process guides, quality standards, relevant diagrams, drawings, and, schematics.   |

## Ontology modelingNext Step Up - Spreadsheets

## Ontology ModelingExpert Tools -  Protégé 

## Structuring information for long-term usageKnowledge archive and evolution

- Need to store not only contextual information about the digital objects, but also knowledge about the relationships used to derive the contextual information
- Semantic/logical relationships
- Procedural/temporal relationships
- Structural/spatial relationships
- Functional relationships

- Data

- Information

- Knowledge

- Capture

- Manage

- Access

**Persistent Archive**

** ****Source: Zimmerman -  DOE/Honeywell**

**Notes:**
Semantic/logical relationships. Relationships can be defined to map from the concepts used to describe the collection to the attribute tags used to annotate the collection. Semantic relationships can also be defined between the domain specific concepts as knowledge bases or semantic maps.
Procedural/temporal relationships. The transformations that are applied to the collection to create the archival form constitute a workflow that represents the ingestion process. The temporal order and explicit transformations can be represented as a set of states through which the collection is processed.
Structural/spatial relationships. The internal organization of digital objects within the collection can be represented as a structural ordering of the tagged elements. The representation of the structure can be expressed using the same types of characterization as needed for spatially tagged data.
Functional relationships. For scientific applications, analysis algorithms are needed to identify features that might be associated with a digital object. The expression of the relationship between the named feature and its presence within a digital object will require the ability to archive mathematical expressions.

## Evolution of information representations

- Self-integrating systems

- Self-describing systems

- Common models of data

- Explicit, formal semantics

**We are still laboring on first 1 1⁄2 steps**

**Information Integration roadmap**

** ****Source: NIST-Fenves**

***Evolution of information representations***

## PLM Maturity Model

- The framework would have enough “knowledge” about the data, process, and business rules to dynamically query, transform, and share the local application’s contents with any other framework subscribers without having to predict the precise nature of interactions in advance

**Notes:**
we must begin to employ technologies that make design deliverables (models, workflow, business rules, dictionaries, etc.) available to the run time layer directly, to enable the dynamic configuration of a wide variety of possible data and process interactions 

## SFOC Review and AnalysisContracting Models – for SSP and next gen programs

**Traditional customer/ supplier relationships**
- Clear lines of responsibility
- Focus of delivery of products and documents
- Not dependent upon data platform (outputs are the deliverable)

- Customer

- Contractor

- Sub

- Sub

**Cooperative partner relationships**
- Less customer/supplier, more community of practice
- Greater sharing of data
- Less reliant on deliverables alone, more reliant on access
- More dependent on data platforms

- Customer

- Contractor

- Sub

- Sub

## Semantic Interoperability – where to start?

- Modelica – physical systems modeling and simulation
- ModelicaXML
- Easy access to Modelica language structure
- Assist in integrating non-simulation applications
- Syntax only, no semantics
- ModelicaOWL

- Adrian Pop, Peter Fritzson
- Programming Environments Laboratory
- Linköping University

## Digital ShuttleSocio-Technical Risk and Knowledge Modeling

- Develop a systematic process for identifying level of information need by various users, and clearly define the specific understanding users maintain in order to make a shared information system work effectively
- Because functional groups often augment their knowledge system in unofficial and undocumented ways, it is important to develop an Inter-Organizational process model that examines all levels of knowledge acquisition, usage and management and to determine information priorities through systematic, socio-technical risk modeling
- Need to determine knowledge representations and risk-informed data management techniques that can be effectively and consistently used across lifecycle areas

## Socio-Technical Risk Model for the Orbiter Processing Facility

- Building the OPF Socio-Technical risk model
- Identify the Top-Level Events and establish In-flight Discrepancy rates using in-flight anomaly (IFA) data and focus group estimates
- Use Focus Groups and the Human Failure Modes and Effect Analysis (HFMEA) process to identify individual failure modes and failure rates
- Focus groups build, evaluate and update fault trees for each top-level event

| Top Level Event | Failure Mode | Type of Failure Mode | Estimated Failure Rate | Contributing Factors |
| --- | --- | --- | --- | --- |
| Mechanical Collateral Damage | Inspection does not catch damage | Normal Error  vs. At-risk Behavior | 
000000 | Distraction
Time Constraints
 etc. |
|  |  |  |  |  |

## Socio-Technical Risk Model for the Orbiter Processing Facility

- Building the OPF Socio-Technical risk model (continued)
- Identify vulnerabilities in the system design (quantitative and qualitative)
- Identify potential prevention strategies
- Update model to determine predicted effectiveness of prevention Strategies
- Continuously update and evaluate the model
- What does the Risk Model add?                                                 The risk model is not a replacement for best practices, occurrence reporting or root cause analysis, but
- it can identify immediate high-impact changes to reduce risk
- it begins to eliminate “seat of the pants” management by providing a risk/data driven approach to managing error
- it can help facilitate the safety culture – showing workers their interdependency in ensuring safety in a non-blame setting

## Digital ShuttleVision: Future State

***Digital Shuttle******Vision: Future State***

- Use Ontologies as generalized knowledge/model representation throughout program
- Provides effective corporate knowledge capture, reuse, integration point
- Creates actionable lessons-learned
- Truly grows the organizational knowledge base
- Create information relationships across lifecycle areas, software systems/databases, and across functional organizations to reduce risk and support system integration/operation
- Make risk models a living part of the Ontology
- Use ontology to validate activity/decision against risk, behavioral, functional models

- Design Expert Advise

- Your design model, reference 1658, is impacted by PRACA
- Report 31452, do you want to review?

- Orbiter PRA

- Feature change

- knowledgebase

- Semantic interpretation

## Resolving object vs. database models

- Pragmatic need to introduce more self-describing, semantically richer objects
- Propose encapsulating common files in a composite object
- Ability to define form, function, connectivity, metadata, relationships, associations in a semantically-consistent annotation
- As opposed to business objects, direct execution of business logic is not the goal, they are a richer encapsulation of instance and class information, i.e. model components
- An Engineering Object (eObj) is a component-based concept that brings together all the metadata needed to support the capture of intrinsic (properties) and extrinsic (process and effects) knowledge relating to the object
- Base implementation on concepts of OWL-Full, preciseUML, and, Java SDO (Service Data Objects)

- CAD shape

- Process
- Part structure

- Additional representations

- metadata

- semantics

- Knowledge Model (EngrObj)

**Notes:**
preciseUML
definition should be unambiguous, questions of understanding, use and conformance can be answered definitively
definition should separate concerns, deal with representation (syntax) and deal with the meaning underlying representation
definition should support integrated modelling languages
definition should be complete, all aspects of a language (including semantics) should be defined unambiguously
definition should be layered and extensible to support the construction of new members of the UML family
definition should have a consistent and disciplined architecture, so that it can be readily understood and easily extended
definition should be checked in a tool
Current UML has semantic weakness (to resolve model ambiguity and facilitate tool compatibility) because it uses a semi-formal notation
SDO
Specification for a programming model that unifies data programming across data source types, provides robust support for common application patterns, and enables applications, tools, and frameworks to more easily query, view, bind, update, and introspect data.

## Digital Shuttle Ontology Engineering Example

**Engineering Domain Knowledge**

**Engineering Process Knowledge**

**CAD**

**CAE**

**Engineering Object**

- Process has Activities
- Activity produces Workproduct
- Workproduct is_approved_by Role
- Workproduct is_reviewed_by Role
- Workproduct is_produced_by Role
- Document isa Workproduct
- Document is_held_in System

**Governance Knowledge**

- Organization has Policies
- Organization has Groups
- Team has Goals
- Team uses System

**Business Concept**

**Process Concept**

**CAM**

**PLM**

## Backup Charts

## The spectrum of knowledge representation

**Source**: Adapted “Figure 7.5: The Ontology Spectrum: Weak to strong semantics”, page 157 of  “The Semantic Web”, Michael Daconta et al., John Wiley, 2003

**Conceptual Model**

**Is subclass of**

- XTM

- RDF/S

- Extended ER

- Dictionary + ? = Taxonomy

- Taxonomy + ? = Ontology

## Semantic Technology allows rules to be shared across applications and enables Interoperability

**Knowledge need not live in each application**

- Middleware

**ERP**

- SI

**Semantic ****Engine**

- QueryOntology Models

- Enterprise Ontology Models

- Interoperability Ontology Models

- SI

**PDM**

- SI

- SI

**CRM**

**Data**
**Warehouse**

- WS

- WS

- WS

- WS

- WS

- WS

- WS

- Application 1

**DB**

- SI

- WS

- Persistence

- Transactions

- Process

- Authorization

- Comms.

**Notes:**
Lightweight ontologies 
A "formal ontology" is an attempt to articulate concepts of interest to a certain locus of usage [140] in a way that is directly processable by particular software technologies for "reasoning" (see 6.4.1). The locus of usage might be a community, an organization, a set of applications, or a set of processes. Conversely, any attempt to articulate concepts of interest for a locus of usage, in such a way that the concepts can be reused in contexts different from that in which they originally appear, may be considered an ontology. 
nteroperability is fostered when we can identify such lightweight ontologies and exploit them for what they really are: informal, partial or tentative attempts at standardization of concepts and terminology. The easier it is to extend the locus of applicability of the implicit ontologies of software systems and business processes, the easier it will be to integrate disparate applications. And therefore, the integration process may benefit from approaches to the capture and intepretation of "informal" and "lightweight" ontologies. These include: 
• software specifications 
• machine-readable forms of dictionaries and thesauri, such as WordNet
• manual efforts and specialized software for extracting concept graphs and behavior rules from text (but the integration process uses only the formalized results) 
 Moreover, we should not expect the exploitation of lightweight ontologies to be a one-pass process. The organization of information for a particular software process creates a new ontology, and therefore, the process of integration creates a new ontology. And that new ontology is the foundation for the next level of software development, and the foundation for the next level of concept standardization. A similar effect can be observed in business processes that become standardized and business processes that become automated. As we do more, the conceptual substrate evolves [143]. And in every case, the new ontological information will initially be captured in the software and in the business communications, not in formal ontological models. 

## moving further up the Knowledge Ladder

- RH

**Notes:**
<RH+MS>

## Digital ShuttleFrom problem to solution

**Design**
**Manufacture**
**Test**
**Operate**

**Maintain**
**Upgrade**
**New Tech**
**New Proc**

- Solution

- Problem

- Lifecycle consistent ontologies
- Effective, reusable data models
- Unambiguous communication

**System Lifecycle**

**Integrated Machine & Human Learning**

**Mass Corporate Knowledge Loss**

**3-D virtual environment for model-based** **simulation, analysis, and knowledge capture**

**Lifecycle Integrated KM - Ontology**

**Disparate Data Sources**

**Multiple Ambiguous Representations**

**No Formal Learning Process**

**Incomplete Data Sources**

**Insufficient Infrastructure**

**Non-interoperable  legacy systems**

**Proactive Knowledge**

**Geographically dispersed workgroups**

**Lack of comprehensive system models**

**Inconsistent configuration control**

**No effective large-scale KM**

**Organizational Learning**

**Digital Libraries**

**Knowledge Modeling**

***Digital Shuttle******From problem to solution***

**Compartmentalized Knowledge**

- Federated Environment for cross-domain/organization collaboration
**Achieve: Organizational Learning, Corporate Knowledge Building**