DIAGNOSTIC AND MAINTENANCE CONTROL SUBCOMMITTEE
07-D MEETING
Baltimore, MD
September 15-16, 2007


07-D Agenda

Saturday, September 15, 2007

The meeting was called to order at 9:00 by Mark Kaufman.

The call for patents, including the showing of mandatory slides, was completed at the SCC20 plenary meeting prior to the start of this meeting.

Agenda was modified and approved by the subcommittee.

Chair’s Report

P1232 PAR will remain active as long as the currently published standard is active. We have a comment on the P1636 PAR extension request. There is a concern from NESCOM about the size of the working group and the working group's ability to complete the standard within the extended period.

Secretary’s Report

Minutes of 07-C 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.

P1522 Discussion

We still have not received any feedback from Bill Ross or Malcolm Brown. Bill Ross did say he wanted the NxTest IPT (especially ATS Framework Working Group) to review the standard. Mike Malesich indicated his willingness to have the working group review.

Bill had indicated in Madrid that he thought the weapon system developers and buyers are the ones that would be more interested in the standard. Malcolm Brown indicated that the UK MoD is in the process of updated Def Stan 0013 and that they might be able to use P1522.

SIMICA (P1636)

With the PAR extension request, we received a comment from NESCOM (Ronald C. Peterson). “Based on activity to date, it would be useful to receive some assurance that the relatively small working group will complete the draft and ballot within the two year period requested.”

Proposed Response: We identified seven active participants. There are numerous participants involved and providing input beyond the seven active ones. Much of this input drove the P1636.1 and P1636.2 standards. Note that P1636.1 has now been approved and P1636.2 will commence ballot shortly. These two standards have driven the completion of the umbrella standard being developed under this PAR. In addition, the draft is nearly complete. It was just not feasible to complete ballot within the time remaining. We expect to go to ballot by June 2008, as indicated in the extension request. This projection has not changed since we submitted our request.

The subcommittee chairs like the above and plan to submit it back to NESCOM.

It would be helpful to have more input from the logistics community. This is because of the tight coupling between the supply chain and the maintenance process. For example, an indication of a potential RTOK/CND problem is a spike in some inventory/part requirement. Tim called for all people to try to get people from the logistics community involved. This must happen before the next meeting, or it will be too late. That said, there was consensus that we need to keep the scope of SIMICA on diagnostic maturation. Specifically, we do not want SIMICA to become a “logistics” standard.

The QA review of SIMICA is complete. Barring further changes, the standard is ready to ballot. Assuming we get the extension on the PAR, we will attempt to obtain a logistics-based review of the information model. By the 08-A meeting, the standard will proceed to ballot with or without input from the logistics experts (contingent upon approval of the subcommittee).

AI-ESTATE (P1232)

We started to discuss the open action items for P1232 and whether or not the extended life of the PAR would permit us to include elements that would not have otherwise been included in the next revision. This led to the discussion on the order constraint. To summarize the discussion, it was decided that the precondition attribute of Action be removed and that the community make use of the preconditions/postconditions/states in ATML's TestDescription schema as interim solution. No action will be taken to modify the standard relative to ATML/TD; however, the issue of order constraints will be reconsidered on the next version or as an amendment to the standard.

We also discussed the validation approach (briefly). The general feel is that there would be benefit from the recommended practice, and it would be good to put a PAR in soon. The working group will discuss this after AUTOTESTCON and decide whether or not to put together a PAR between this and the next meeting.

We did an initial review of some of the 6.2 services. Some entities were identified that need “name” attributes.

Lots of discussion took place around loading and saving models. The consensus was that the save/loadModel and save/loadExchangeModel can be reduced to just the first set. (I.e., we don't need separate exchange format-specific services). To do this, the load service will be required to determine the type of file to be read (native format, part 21, or XML), and the save service must specify one of those three types. At the same time, there are two approaches to handling these services: one where an explicit path is specified, and one where just a name is provided and the reasoner manages file location. Both of these options will be supported. In addition, paths will be specified via URN.

There was some confusion over the purpose of set/restoreCheckpoint that may suggest an additional pair of services is required (e.g., set/restoreWaypoint). The checkpoint services are intended to support suspending and resuming a session or recovering from session failure. The waypoint services would be intended to support backing up to a defined step in the session trace. There was no consensus on how the managing of checkpoints was to be accomplished. It was referred back to the working group to determine who is in control (i.e., application vs. reasoner) and whether a file path needs to be specified.

It has been suggested that the model for selecting/specifying tests and applying outcomes should change. The current standard recommends a test (with select_test) and associates that test with the current step. Then the outcome of the test is applied for the state to be updated. If a test other than the one recommended is to be evaluated, it must be overridden with assign_tests. Under the new model, assign_tests would be deleted because there would no longer be an assumption that the chosen tests (actually actions) are automatically associated with a step. The association now occurs when the outcomes are assigned. A byproduct of this is that select_test becomes recommendActions and apply_outcomes operates on any action rather than just tests. In recommendActions, a list of actions is returned where the length of the list is specified, and the list is interpreted as a ranking of recommended actions. One or more of the recommended actions might be taken. If the full list of n actions cannot be provided, a shorter list will be returned without an error being generated.

Need to add a new service to permit the assertion of any outcome in the model.

The review of the service, getMostLikelyDiagnoses, was deferred until later.

The services, estimated_..._to_isolate/repair/resources have been referred back to the working group to put together a proposal explaining what they mean.

Should merge requestTestResourcesNeeded and requestRepairResourcesNeeded into requestActionResourcesNeeded.

For showSessionTrace, this is expected to be used as a way to play back all or part of a session during the diagnostic process. The current specification of STRING is weak but could be replaced with serialized XML. This needs to be fleshed out further rather than simply abandoned.

Darryl raised the question of whether or not the 6.1 services should be retained. Log 466 provides more detail. It seems to be premature to make this decision given some of the “advanced” use cases involving maturation or learning where multiple applications are interacting to make this happen.

Sunday, September 16, 2007

P1232 (continued)

The started with a summary of the P1232 activities from Saturday. Michelle Harris led the discussion. The action items were reviewed again, and the models were tweaked and twiddled.

We started by finishing with the slides Darryl presented, focusing specifically on the probability issues. It was decided that an “ActualUsage” entity be added to the DCM to provide an “index” into the associated probability distributions from the CEM. This entity would include, at a minimum, attributes for time index, units, and identification of the top-most repair item. A requirement would be imposed that the usage implicitly “flows down” to child RepairItems. The entity would be shown as a list connected to Step. The list structure would impose an order of precedence in the event a child RepairItem has multiple parents. In this case, later “parents” in the list would have precedence (i.e., would override earlier parents). The attribute is placed on Step to permit usage to change through the session.

Discussion moved to conformance in an attempt to provide guidance. It was suggested that, if 6.1 services are to be provided, then there should be no differentiation between Core and Optional elements. In addition, even though the focus is shifting to conforming to reasoning models, all applications must be able to read all CEM elements (whether optional or not), even though they may not use them.

Two types of conformance are envisioned:

  1. Model exchange (i.e., the model conforms)

  2. Reasoner services

This is no different from the current standard; however, the question was raised about how/whether a reasoner conforms if its operation depends upon (i.e., requires) optional elements within a model. Three “levels” of conformance were identified:

  1. Minimal/core elements and capabilities

  2. Required elements plus optional to support added features, but the optional are not required.

  3. Required elements plus optional to support added features, but the optional are required. In this case, the implementation would not be conformant.

In all cases, any application identifying that it implements some aspect of AI-ESTATE, whether claiming conformance or not, must specify any exceptions.

P1636.2 (MAI)

Joe Stanco walked through the current MAI schema.

During the review, it was pointed out that existing MAF systems incorporate a job status field. The MAF is not “generated” until the job status is complete; however, people can still access a MAF in process within the hosting information system. Therefore, it was suggested (and accepted) that a “MaintenanceActionStatus” complex type be added to the top level. This would include an enumeration of Open and Closed as well as a qualifier, which would be a string.

The schema was thoroughly reviewed and suggestions made for improvement.

Next we did a quick review of the structure of the MAI standard document.

Roadmap

The roadmap was reviewed and updated.

Users Guide

We need one.

Agenda Review

The agenda for the next meeting was put together and approved by the subcommittee.

The meeting adjourned at 4:00 pm.

Attendees

Name

Affiliation

Email

Day 1

Day 2

Alwardt, Tony

Boeing

anthony.l.alwardt@boeing.com

X

X

Busch, Darryl

Honeywell

darryl.busch@honeywell.com

X

X

Ellis, Keith

EADS Test & Engineering Services

keith.ellis@eads-ts.co.uk

X


Finklea, Ken

DRS

kfinklea@drs-tem.com

X

X

Frank, Brit

US Army

brit.frank@us.army.mil

X

X

Gerstein, Bill

Hamilton Sundstrand

we.gerstein@hs.utc.com

X

X

Harris, Michelle

Lockheed-Martin

michelle.l.harris@lmco.com

X

X

Helton, Alicia

Lockheed-Martin

alicia.helton@lmco.com

X

X

Kaufman, Mark

US Navy

mark.kaufman@navy.mil

X

X

Modi, Mukund

NAVAIR

mukund.modi@navy.mil

X

X

Neag, Ion

Reston Software

ion.neag@restonsoftware.com

X


Ralph, John

Northrop Grumman

john.ralph@ngc.com

X

X

Schieber, Michel

EADS Test & Engineering Services

michel.schieber@eads.com

X

X

Sheppard, John

Johns Hopkins University

jsheppa2@jhu.edu

X

X

Stanco, Joe

SSAI

jstanco@ssai.org

X

X

Stumptner, Markus

University of South Australia

mst@cs.unisa.edu.au

X

X

Wilmering, Wilmering

Boeing

timothy.j.wilmering@boeing.com

X

X


Action Item Summary

Old Action Items


New Action Items


Open Issues

Items Logged at 07-D Meeting

Proposed 08-A Agenda