DIAGNOSTIC AND
MAINTENANCE CONTROL SUBCOMMITTEE
08-A MEETING
Orlando,
FL
January 15-17, 2008
Call to Order
Approval of Agenda
Reports
Chair's report
Secretary's report
Liaison Reports (CS, I&M, AES)
Brief presentations
Joint meetings as necessary with all working groups
PAR for New Recommended Practice for XML/EXPRESS Instance Document Validation
Finalize AI-ESTATE
Document review
Prepare for ballot
Conformance Discussion
SIMICA Discussions
Document review
Prepare for ballot
MAI Discussions
Document review
Prepare for ballot
P1522 Re-organization
Future of document
Final Discussions on All Topics
Review Old Action Items
Review New Action Items
Set Time and Location of 08-B Meeting
Set Agenda for 08-B Meeting
Adjourn
Agenda was reviewed and approved by committee vote.
Chair’s Report
Tim W. gave a brief chair report.
Secretary’s Report
Ken Finklea agreed to be secretary for 08-A meeting.
Minutes of 07-D meeting were reviewed and approved.
Action Items and Open issues were reviewed and modified as appropriate.
Liaison Reports
CS liaison had nothing to report.
I&M liaison had nothing to report.
AES liaison had nothing to report.
Presentations
No presentations were given.
SIMICA Discussions
The committee reviewed Draft 1.2 of P1636.
In Figure 1, Remove the P from 1636.1 Test Results. This component is no longer preliminary.
There was a recommendation to remove definitions that did not appear the body of the document. The following definitions were removed: Ambiguity, Ambiguity Group, Diagnostics Procedure, Diagnostic Strategy, False Alarm, Fault Detection, Fault Isolation, & Test Strategy. We also added definitions for Level of Indenture & Diagnostic Maturation and modified Level of Maintenance.
Removed any references to 1636 services and tried to emphasize that model element definitions would support user defined service architectures based on those elements.
Model Changes:
Mukund presented an input from Craig McCullough at NAVAIR on the SIMICA information model (reference Figure D.2). He suggested the addition of three new design models: Maintenance, Availability, & Obsolescence. In addition, he suggested that the Logistics Model encompass all of the other design models. It was a consensus of the group that the Maintenance and Availability models certainly might provide strong contributions to the Design Model, but that the Obsolescence Model had little to do with diagnostics. In addition, we suspected that his interpretation of the Logistics Model did not use our strict interpretation. We suggested changing the name of the Logistics Model to Supply Chain Model to be a more accurate description.
Craig also suggested adding two design libraries: Maintenance Plan and Provisioning Documentation. It is the committee’s interpretation that both of these are document products of other analyses supported by SIMICA sub-models. Mukund has taken the immediate action to relate this discussion to Craig, and specifically ask him to define Maintenance model and Availability model. Additionally, he will ask him if a connection exists between an Obsolescence model and Diagnostics that we are overlooking.
It was suggested that MeasurementAsset and SupportAssest be defined as “subtypes” of TestResource for consistency with other definitions.
It was suggested to spell out the acronym WAN in the definition of SystemCollection.
A clarification of Conformance requirements was suggested and applied. The SIMICA spec is a unifying top-level conceptual information model and thus does not have conformance requirements.
Tim had substantially modified the bibliography.
WebEx initiated by Tim W. to remotely include other committee members.
SIMICA Discussions-
Discussion on the previous day’s input from Craig M., specifically the need for a Maintenance Plan or Provisioning Documentation as part of the Design Library. John S. recommended someway for the committee to retain a “current thoughts” or “relevant thoughts” list. Tim W. recommended some type of DMC Wiki.
Review of suggested definitions on a System Maintainability Model and a System Availability Model supplied by Craig McCullough from NAVAIR documentation.
Generally agreed that the Logistics Model should be renamed to Supply Chain Model and that this term is a generally accepted term.
Maturation scope discussion – What are the elements that we need to consider that may drive diagnostics maturation updates? List could be endless. Opened Issue 08A-1 on this topic.
John S. to review suggested changes to SIMICA model and provide updates to committee by end of the day.
Michel suggested that a Risk Model for the development of diagnostics be included in the Design Models as this study would improve the diagnostic performance.
1232 WG Discussions
Pat suggested adding a Grey Scale Health Indicator (ATS Framework). Tim W. asked if anyone has defined what constitutes Grey Scale Health. It is generally accepted that agreeable definitions still do not exist. However, the committee does not want to delay the specification balloting.
Pat submitted a recommended definition of Grey Scale Health.
JS - Does Grey Scale Health apply to a Diagnostic or a Diagnostic Outcome?
DB added that Grey Scale Health applies to specific instances.
TW – Gave reference to Grey Scale Health being associated with multiple outcomes.
JS – Do we associate it at the top level outcome entity? We could add an attribute to Diagnosis Outcome that could allow specific instance modification (not desired).
DB – Severity is only associated with mission criticality and is a prioritization of outcomes. Grey Scale Health is a degradation of a specific outcome and how to modify reactionary behavior.
TW – Will services be complete by the next meeting? Need an action item to create a proposal for Grey Scale Health by the next meeting.
Action item assigned on Grey Scale Health proposal.
1232 Conformance Requirements Proposal Review –
Any service that is not supported should report an exception.
JS – Still like the conformance matrix for documentation reasons
DB – Would like to have ability to include hypothesis inputs. There is not a definition by the specification of what must happen when a test result outcome received from a client.
JS – When observed outcomes are received, the specification must define some reaction.
The std does not specify to optimize by cost if provided, but optimization criteria are provided.
PK – Question on wording of Conformance definition. Specific meaning of erroneous processing and reasoning conclusions was questioned. TW added clarification wording.
DB – Question on application ability to write model elements back out.
JS - Conformant application shall read all required and optional elements and write model instances that will validate
DB – Problem: To validate an extended instance you need the extended schema. If I want to extend some entity I need to create a new entity. Now with this new entity such as “ext_widget”), how will the application process this entity with this name? Darryl has proposed a solution to be reviewed at a later date.
JS – To what extent do we want to permit extensions? How does an application recognize an extension?
TW – Need to have some method to extension.
JS – May need to revisit Part 28 (XML Schema Update)
DB – Problem with Part 28? Default is that no relationships map to entities.
Action item was assigned to Darryl to review Clause 4.4 to see if it needs modification and ensure it supports model exchange in both EXPRESS and XML.
A conformance definition was agreed upon by the committee and documented. This definition removed the need for the 3 levels of conformance and model exchange format conformance definitions presented earlier.
Discussion came up about the need for multiple categories of conformance
Action Item generated for Mark and Tim to rework the conformance section to allow conformance under one of two categories or both. Categories are conformance to services or models.
TW - Do we what to provide a means for documentation or do we leave it to the user?
Tim recommended the creation of a matrix that documents document exchange and user documentation of application services.
MAI Discussions –
Joe presented the P1636.2
Joe presented the MAI schema to include MAI attributes
JS - Requirement for MAI from IEEE is for an XML document. Anything we do must not violate this requirement.
JS – Most of the Hardware Instance information is in the Common Model.
TW – Suggest that we divorce ourselves as much as possible from Common
General discussion on the need for indentured data elements for equipment resources used to affect a Maintenance Action. Agreement that we should not include data elements beyond name, part number, and serial number for equipment used.
TW – What is Historical MAI?
Joe – An optional element established to tag references to other relevant MAIs
Lengthy discussion on the classification of GeneralMaintenance and ReactiveMaintenance. Shouldn’t we just classify as either scheduled or unscheduled. A recommendation was made to have a single complex type “Maintenance” with two types: scheduled and unscheduled. The unscheduled would have a “Basis” to capture the causal elements. We reviewed the information model and agreed that the recommendation had parallel agreement (EXPRESS to MAI Schema).
Suggested that element name “Basis” be changed to “Reason”
Discussion on symantics of AssociatedTestResults and NonstandardTestResult. Recommendation to change AssociatedTestResults name to StandardTestResults. Recommendation to change AssociatedFailureCode name to ParentFailureCode.
Recommendation to change AssociatedDiagResults name to AssociatedDiagSession.
Recommendation to change facilityCapability to an optional attribute within Maintenance complex type.
Recommendation to create a “Facility” element and move all facility attributes up to the Maintenance event.
Recommendation to remove ReferenceInstanceDocument element
Recommendation to remove “Description” element .
MAI Schema Discussions (continued from January 16, 2008 above)
Currently the XML schema for ActionPerformed does not allow mix and match of action types. The definition of Maintenance Action event does not describe the scope of the event.
JS is changing the information model to reflect a 1-N action list for each MaintenanceEvent. The MaintenanceAction was changed to an Abstract type. Therefore, each MaintenanceAction can select only one action element.
MaintenanceActionTime represents aggregate computed action time. Committee decided to make MaintenanceEndTime a mandatory record not optional. This would allow for the calculation of Calendar/Wall Clock Time.
Why do we have SerialNumber under RepairAction? The SerialNumber represents a subcomponent of the MAI. We need to have a PartNumber for each Serial Number in the MAI. It was found buried deep in Definition. So there is a PartNumber as part of Definition and a SerialNumber for each RepairAction, RemoveAction, & InstallAction.
NoAction is a null set for items like No Fault Found or Can Not Duplicate.
MAI Information Model Discussions
John S. reviewed the MAI information model.
Action Item: John, Joe and Mukund to harmonize the information model, definitions, and the schema.
Discussion of the definition of Relative in relation to SkillLevel.
MaintenancePersonnelTime may need to be changed to a calculated value from the maintenance action. John S. to review.
P1636.2 is being updated and scrubbing the document for review. Plan to put the document out for review in March.
Action item generated for John, Joe, & Mukund to provide P1636.2 document to the DMC membership for review and comment before the next meeting (April 2008)
SIMICA Discussion
Tim W. named as SIMICA Ballot Designee
Motion initiated and approved to begin SIMICA Ballot Process.
Part 28 Discussions:
Original intent was for 1232 to provide an XML exchange format, prior to ATML, due to the limited use of EXPRESS.
How do we harmonize the goals of 1232 and ATML? The main issues are extensions and validation.
DB – Use of ATML Common may not be easy at all with 1232.
Members of DMC and TII met to discuss harmonization of their respective approaches to XML exchange and well as other SCC approaches and standards.
It was agreed that differences in approaches may be inevitable at this point in time, but discussions such as these should be ongoing in an effort to eventually harmonize approaches. For instance, a compromise information representation may utilize OWL or other standardized Ontological approaches to semantics representation.
Committee discussed XML options and at DB suggestion that the most expedient way to provide an XML exchange format for this revision of 1232 is to roll our own and be as ATML like as possible while still satisfying validation and extension constraints.
Committee revisited the issue of validating XML against EXPRESS and decided that it is desirable to provide such a capability as an informative annex to the current revision and to remove any XML exchange format conformance from the conformance clause. Darryl B. will provide a XSLT and instructions on how to use as an informative annex in the current revision.
Agenda Review
The agenda for the next meeting was put together and approved by the subcommittee.
The meeting adjourned at 1315 Thursday January 17, 2008.
|
Name |
Affiliation |
|
Day 1 |
Day 2 |
Day 3 |
|---|---|---|---|---|---|
|
Busch, Darryl |
Honeywell |
|
|
|
|
|
Chun, Kahn |
USMC TMDE |
|
|
|
|
|
Davis, Tim |
NAVAIR |
|
|
|
|
|
Fandino, Oscar |
LM STS |
|
|
|
|
|
Finklea, Ken |
DRS |
|
|
|
|
|
Frank, Brit |
US Army |
|
|
|
|
|
Gorringe, Chris |
EADS T&S |
|
|
|
|
|
Harris, Michelle |
Lockheed-Martin |
|
|
|
|
|
Helton, Alicia |
Lockheed-Martin |
|
|
|
|
|
Horton, Orman |
USMC TMDE |
|
|
|
|
|
Jimmerson, Carey |
AMRDEC |
|
|
|
|
|
Kalgren, Pat |
Impact Technologies |
|
|
|
|
|
Kaufman, Mark |
US Navy |
|
|
|
|
|
Lopes, Teresa |
Teradyne |
|
|
|
|
|
Modi, Mukund |
NAVAIR |
|
|
|
|
|
Savage, Howard |
SCI |
|
|
|
|
|
Schieber, Michel |
EADS Test & Engineering Services |
|
|
|
|
|
Sharone, David |
LM STS |
|
|
|
|
|
Sheppard, John |
Johns Hopkins University |
|
|
|
|
|
Stanco, Joe |
SSAI |
|
|
|
|
|
Wilmering, Wilmering |
Boeing |
|
|
|
Old Action Items
Action Item 06C-3: Alicia Helton will examine the 1232 models for elements that may be related or duplicated in a P1636.x schema. Such identification will enable use to ensure consistency between the schemata and provide a mapping as necessary.
Status: OPEN
Action Item 06C-4: Pat Kalgren to use his AUTOTESTCON 2006 paper to start developing a prognostics annex for 1232. This paper will provide a set of definitions as a starting point.
Status: OPEN Michelle will contact Pat to see if this is still feasible
Action Item 07A-3: Darryl B. to obtain a description of the operational/environmental information from recording devices for a commercial platform relevant to diagnostics.
Status: OPEN
Action Item 07A-7: Darryl B, Tony A., and Alicia H. to provide a recommendation for specifying services via a transaction-based approach for P1232. The recommendation will also include specification of the 6.1 and 6.2 services.
Status: OPEN Specification still remains to be completed.
Action Item 07A-8: Darryl B. to complete a proposal for the XML schemas and validation approach for P1232.
Status: OPEN John R. added to action item to help Darryl. Validation approach to be moved to a separate recommended practice. XML schemas still need to be completed.
Action Item 07A-10: Darryl B. to provide proposed text for the conformance section of P1232.
Status: CLOSED Tim W. and Mark presenting a proposal at 08-D.
Action Item 07A-12: Mark K. to draft a PAR for revising P1522.
Status: OPEN
Action Item 07A-13: P1232 working group co-chairs to prepare final draft of P1232 for April meeting.
Status: OPEN, Modified to be due electronically by March 15, 2008.
Action Item 07B-6: Michelle H. to add text to the P1232 standard expressing that the focus of the models is to define semantics and to facilitate information exchange. As a result, it is possible, if not likely, that an instantiation of the model will not be optimized for computational purposes (wordsmithed for clarity).
Status: OPEN
Action Item 07B-7: Michelle H. to investigate how they are storing the probabilities in the probability tables. Two questions to be resolved: 1) Are the diagnosis outcome probabilities only priors, therefore, only requiring one value per outcome? 2) How are the state values ordered in the likelihoods associated with the test outcome probabilities? This ordering needs to be specified in the standard to ensure exchangeability.
Status: CLOSED Diagnosis outcome probabilities are only priors, therefore, only require one value per outcome. Alicia to present state value ordering at 08-B.
Action Item 07C-6: Brit Frank to complete a QA review of the P1232 draft prior to submission to MEC.
Status: OPEN
Action Item 07D-1: Tim W., John R., Michelle H., and Mukund M. to contact logistics experts/SMEs at their respective organizations to review the SIMICA information model to determine if there are any blatant omissions or issues with the current model as well as solicit involvement in subsequent work on the standards. By the 08-A meeting, the standard will proceed with or without input to ballot (contingent upon approval of the subcommittee).
Status: OPEN Mukund obtained input to the SIMICA model
Action Item 07D-2: John S. to add “name” attributes to: DCM.Session and CEM.Resource.
Status: CLOSED
Action Item 07D-3: Darryl B. to write a constraint that Action.Cost.CostCategories in the CEM should be unique.
Status: OPEN
Action Item 07D-4: Darryl B. to write an introduction to ISO 10303-21 as an informative annex to P1232.
Status: OPEN
Action Item 07D-5: John S. to modify the DCM to include an “ActualUsage” entity as described in the 07-D minutes.
Status: CLOSED
Action Item 07D-6: Darryl B. to add relevant services to support “ActualUsage.”
Status: OPEN
Action Item 07D-7: Alicia H. and Darryl B. to develop a service for asserting outcomes.
Status: OPEN
Action Item 07D-8: Joe S. to add a complex type to the top level of MAI to capture MaintenanceActionStatus. This would include an enumeration of Open/Closed as well as a string qualifier.
Status: CLOSED
Action Item 07D-9: Joe S. to define a Personnel complex type. Once created, it will be added as a child of Resources. The rest of the schema will then be cleaned up wherever personnel are involved.
Status: CLOSED
Action Item 07D-10: Joe S. to define a new complex type capturing the current structure involving AssociatedDiagnosticResult and the choice of Observation, AssociatedTestResults, and AssociatedFailureCode. Then create a choice under ReactiveMaintance that chooses between a reference to an MAI at the next level up or to this complex type. The complex type is called “Cause.”
Status: CLOSED
Action Item 07D-11: Joe S. to modify the schema to represent the following sequence of events: 1) Document information received from prior level (or something that initiated this maintenance action), 2) Perform sequence of events and collect information (e.g., cause-action-cause-action-...) to determine the course of action at this level, 3) Take corrective action, and 4) Do RFI/recertification.
Status: CLOSED
Action Item 07D-12: Mark K. to submit formal response to NESCOM on SIMICA.
Status: CLOSED
Action Item 07D-13: John S. to complete the information model on MAI and send to Darryl B.
Status: CLOSED Model completed and posted on web
Action Item 07D-14: Darryl B. to derive an XML schema from the information model and distribute to the subcommittee for review as an alternative to the emerging schema.
Status: OPEN
New Action Items
Action Item 08A-01: Darryl, John S., & Pat K. to generate a proposal for a Grey Scale Health indicator for services and for the DMC but not necessarily for calculating specific Grey Scale Health. Proposal due at the April DMC Meeting. If the proposal is not ready for the April Meeting this action item will be moved to Open Issues for future revisions of this standard.
Status: OPEN
Action Item 08A-02: Darryl to review Clause 4.4 to see if it needs modification and ensure it supports model exchange in both EXPRESS and XML.
Status: OPEN
Action Item 08A-03: Mark and Tim to rework the conformance section to allow conformance under one of two categories or both. Categories are conformance to services or models. Conformance to models only, models and model manipulation services, or runtime services (checkboxes not levels). Remove XML data exchange from conformance.
Status: OPEN
Action Item 08A-04: John, Joe and Mukund to harmonize the information model, definitions, and the schema.
Status: OPEN
Action Item 08A-05: Brit F. to QA SIMICA prior to MEC.
Status: OPEN
Action Item 08A-06: Tim W. to initiate SIMICA MEC followed by the rest of the ballot process after QA.
Status: OPEN
Issue 01C-1: Testability metrics based on maintenance philosophy, such as Fault Resolution, can provide a means of validating predictive measures. At this point, the information models used to support definition of metrics in P1522 are insufficient to address maintenance philosophy. Need to add a link to the SIMICA information model to reference P1522 and update P1522 to specify both predictive and actual measures. Then need to emphasize the role of MAI in collecting data based on maintenance practice. Still need something to make sure the predictive measures in P1522 reflect those maintenance practices. All of this is contingent upon P1522 surviving.
Status: OPEN Low Priority. Link from SIMICA to a testability model was added
Issue 06C-1: IEEE Std 1522 is not currently being used. Need to examine reasons for this and determine the future of the standard. Some possibilities to examine include: Does it a need management component (ala MIL HDBK 2165)? Are metrics too inaccessible due to tie to 1232? Is it simply a publicity/perception issue? Is there resistance to objective accountability? Discuss with program managers (Russell Shannon—NAVAIR).
Status: OPEN High Priority John S. and Tim W. discussing with DoD and MoD reps, reference action items 07C-2/3.
Issue 07B-1: The current order constraint in 1232-2002 is difficult to understand and, therefore, difficult to use. The DMC decided to “minimalize” the order constraint to focus only on preconditions and added actions to the model. It is recognized that this minimalist construct is at best suboptimal and possibly “broken.” Unfortunately, timing prevents a new construct being included in the model, and the DMC felt something needed to be there to address ordering. For the next revision, a more expressive and usable order constraint facility needs to be incorporated into the model, replacing the current minimalist construct. One proposal on hand is Log #451.
Status: OPEN Medium Priority
Issue 07C-1: Need to perform a trade study to determine what new services are actually required. This is essential for establishing a usable scope for the service specification. The focus here is for the next revision of the standard.
Status: OPEN Low Priority
Issue 07D-1: These standards (especially AI-ESTATE) are difficult to understand due to the large number of options available to an implementer. It is really important to provide some kind of guidance to the implementer. The hope is that a User's Guide can be put together once the revision has cleared its next ballot.
Status: OPEN Medium Priority
Issue 08A-1: Craig M of NAVAIR suggest several additions to the SIMICA model at the 08-A meeting. One of those suggestions was to add a subtype of Design Model: Obsolescence Model. The question is whether the Obsolescence Model can be used a basis for triggering a maturation event and thereby affecting the Diagnostics Model. John S. has the use case (Asset Specific Diagnostics).
Status: OPEN Medium Priority
Issue 08A-2: John S. and Darryl B. raised the issue of Part 28 for XML schemas to support validation of instance models against the information model. The general issue of validating XML instance documents against EXPRESS information models needs to be explored, whether using a schema derived from Part 28 or an XML schema geared toward XSLT translation to Part 21.
Status: OPEN High Priority
#467 CraigMcCullough SIMICA Input.ppt
#468 Gray-scale health.htm
#469 New 1232 Conformance 1-1-jws-tjw.doc
Call to Order
Approval of Agenda
Reports
Chair's report
Secretary's report
Liaison Reports (CS, I&M, AES)
Brief presentations
Joint meetings as necessary with all working groups
PAR for New Recommended Practice for XML/EXPRESS Instance Document Validation
Finalize AI-ESTATE
Document review
Prepare for ballot
SIMICA Discussions
Review ballot progress
MAI Discussions
Document review
Prepare for ballot
P1522 Re-organization
Future of document
Final Discussions on All Topics
Review Old Action Items
Review New Action Items
Set Time and Location of 08-C Meeting
Set Agenda for 08-C Meeting
Adjourn