DIAGNOSTIC AND MAINTENANCE CONTROL SUBCOMMITTEE
08-B MEETING
St. Louis, MO
April 22-24, 2008


08-B Agenda

Tuesday, April 22, 2008

Agenda was reviewed, modified and approved by committee vote.



Chair’s Report

Tim W. gave a brief chair report.

1636.1 is now an official standard, published in March 2008. P1636 (SIMICA) approved by MEC and ready for ballot.



Secretary’s Report

Minutes of 08-A meeting were reviewed and approved.

Action Items and Open issues were reviewed and modified as appropriate.



Liaison Reports

CS liaison: IEEE ad hoc “best practices” Standards Committee reviewing SCC20. Secretary received list of questions and responded to it.

I&M liaison had nothing to report.

AES liaison had nothing to report.



Presentations

No presentations.



Test Results questions from Kevin Coggins

1. In the 1671.x standards / schema, there is a UUID that can be used to reference an instance from another instance, say for example referencing a UUT Descrption instance from a Test Configuration instance. Please correct my terminology if I get something wrong. In Test Results, there does not appear to be a mechanism to reference the UUID of the corresponding UUT Description, Test Configuration, etc. In an analysis scenario, if I want to see how a certain TPS is performing, and I start at the MTPSI, or even the Test Configuration, I do not see a standard method to link to Test Results via a UUID.

Use TestResults/UUT/DescriptionDocumentReference@uuid to reference a UUT Description instance document

There is a similar element for referencing a TestStation document, but I could not find one for referencing a TestConfiguration document. This is probably an oversight. You could create an extension, similar to the UUT node, or use TestResults/References/Reference with @name = “TestConfiguration” and @uuid = <uuid of your document>.

2. I cannot determine if a TestResults file is valid on its own merit. I do not know if a test was skipped at runtime (Outcome can only be PASS, FAIL, or ABORTED). If I cannot link this to a Test Configuration / Test Description, I cannot get to some parameter that tells me that a test was required, and in comparison to the Test Results determine that a test was not run.

You are correct, a “Skipped” value would probably be useful. If you are able to record skipped tests in your run time, and want to go around the limitation of the current schema, you could assign by convention an Outcome with value = “Aborted” and qualifier = “Skipped”. Not very nice, but easier that having to compare with TestDescription.

3. How can I tell from TestResults that a test was manually forced to the GO condition?

I believe that Events are intended to handle user interaction. Using them to record forced GO conditions is probably not a big stretch. You could record an Event under Test/Events with a name = “ForcedGo” and “source” = “Operator”. Again, not very portable – this would be a convention understood by only your run time.

Second option is to notate Outcome=”passed” qualifier=”FORCED”.

4. I do not see that with a Test Result I can put a user comment or event comment, such as FORCED GO, etc.

True, you can do it only for the entire Test. For individual Test Results you may need to create an extension. Or you could record Events under the parent Test and put in Event/Data an element with name = “TestResultID” that references the ID of the TestResult.


Presentations

Test Group suggestion: Tony A. has a use case that needs environmental context data within a TestGroup. Current structure requires extension.

Suggestion from Tony A. that EnvironmentalData element be moved within schema to subordinate of Test (by inheritance, will also be child to TestGroup).



AI-ESTATE Discussions

Darryl joined the meeting via telecon, and discussion turned to the Part 28-generated XML schemata. Darryl walked the group through an instance document generated according to the Part 28-generated schema. Darryl had a comment concerning how Part 28 handles class hierarchies. Part 28 handles inheritance by copying needed elements in the schema for the subtypes.

Wednesday, April 23, 2008

SIMICA Discussions (Brief)

The ballot for P1636 has commenced, and the announcement should have been received 4/22/08. The ballot period ends 5/22/08



IEEE Std 1522-2004

The testability/diagnosability characteristics and metrics standard was published in 2004 but has never “caught on.” The five year period for the standard ends in 2009. Both DoD and MoD representatives were contacted, and both indicated they have no use for the standard. A motion was made at Steering yesterday, contingent on DMC approval, to remove the 1522 standard.

Motion: John S. moved that the 1522 standard be withdrawn. Seconded by Michelle H. The motion was passed without discussion or objection.



MAI Discussion

Joe S. reviewed the changes made to the MAI schema since the last meeting.

Tony A. raised a concern about being able to incorporate multiple MAIs into a single MAI document. No consensus was reached on whether or not a change was required, and it was suggested that the issue be deferred to the trial-use period to see just how big of an issue it is.

An issue was identified that one needs to be able to access the specific test results that indicate the failure leading to the maintenance event. This is leading to a need to modify the schema and information model. John R. will provide a proposal to both Joe S. and John S.

Discussion then moved to reviewing the draft standard itself. Several editorial recommendations were made. The entire subcommittee needs to review the draft to provide a good scrub on the textual descriptions.



Next Meeting

John S. offered to host the 08-C meeting at the Homewood Campus of Johns Hopkins. The subcommittee decided to target July 15-17, 2008.



P1232 Discussion (Part 2)

Motion: John S. moved to drop the XML/EXPRESS Validation Annex from the standard. It was seconded by Michelle H. Discussion focused on usability of the standard with and without as well as the concern of having the resources available to complete that part of the standard. The motion passed without opposition.

The subcommittee then called in to the conference bridge where the group was joined by Darryl Busch, Pat Kalgren, Oscar Fandino, and Dave Sharone. The meeting was turned over to Michelle as working group chair.

Clause 6.2 for reasoner services are almost finished. The question was asked about whether or not to leave the current 6.1 services “as is.” It appears that is the direction they are going. With respect to the the WSDL specification, the question was raised about whether to include the WSDL and whether or not it should be normative.

Discussion returned to whether or not to use the Part 28-based XML schemata. The consensus of the group is to proceed with Part 28 for the XML schemata. The plan is to use the ATS Framework AI-ESTATE demonstration to generate example XML instance documents that might be incorporated into the standard. Given the planned timing of the ballot process, it is likely the examples would need to be incorporated as a result of a comment on the ballot.

The discussion turned to the Impact Technologies proposal for adding gray-scale health. The current proposal is not likely to be sufficiently mature to include in the version of the standard to be balloted under the current PAR. The consensus was that the two proposals (Darryl's and Erol's) are not sufficient for the current version of the standard (since the standardizable elements of prognostics are still elusive); however, those interested are encouraged to continue to work the issue. If a viable proposal is developed in time, then it will be included in the draft. If not, the scheduling of tasks on the draft will not be impacted.

Another review of the information models focused on two items. First, explanatory text on Context (which needed to be renamed ContextState) was included to explain that the attribute “mustOccurIn” on Action, Diagnosis, and SystemItem must be “disjunctive” (i.e., at least one is required, but not necessarily all are required). Second, manual editing of the information models will be required prior to submitting the document to do the following:

The definitions for GOOD, BAD, CANDIDATE, UNKNOWN, and USER_DEFINED were reviewed. John S. needs to incorporate those definitions into the model.

Darryl then walked through the current draft of the 6.2 service specification. The clause includes an EXPRESS-based specification of the service followed by definitions of parameters, EXPRESS code for any needed data “structures,” exceptions, usage notes, and information on the effects on the DCM. The consensus was the new structure for clause appeared to be well thought out and comprehensive in its specification of the services. Tim W. pointed out that it would be good to make sure the 6.1 specification is developed consistent with 6.2.



Conformance

The conformance section was reconstructed.

Michelle asked, “If I choose not to implement 6.1 or 6.2 services, do I need to respond should a client attempt to use them?” No. But it should be clear what services the application supports.

Thursday, April 24, 2008

MAI (reprise)

Joe S. presented a proposal for relating specific test results to specific maintenance events within the MAI schema. Some issues were identified with the specific indexing into the document. This can be fixed under the current action item.

Joe also brought the possibility of adding a new entity called “ancillary data” using a named-value pair. The subcommittee decided such a structure was not appropriate in a semantic model. The proposal was not adopted.



P1232 (Part 3)

The discussion returned to the extension mechanism. After considerable debate, it was suggested that a sentence or two be put at the end of the conformance section indicating that a) extensions to any AI-ESTATE model shall be defined within a separate schema, b) those extensions shall not cause applications that use conformant models to “break” when using those extended models, and c) an extension to an AI-ESTATE model is non-conformant to the standard. The intent includes the point that conformant and non-conformant parts of the application can be identified. Also, to be conformant, an instance document shall not contain any extensions. Also, any application can provide services beyond those defined in this standard; however, such services will not be recognized as conforming to the standard.

To summarize the discussion, three options appear to be on the table:

  1. Enforce extension through subtyping and derivation of defined types.

  2. Permit extension of any kind with the intent that they not abuse semantic definition of the existing models.

  3. Permit no extensions, as described in the paragraph above.

Show of hands indicated 14 were not opposed to #1, six were not opposed to #2, and five were not opposed to #3.

Motion: Bill G. moved that AI-ESTATE will enforce extension through subtyping and derivation of defined types. It was seconded by Alicia H. (9-0-2) The motion carried.

Action items and log items were reviewed.

The agenda for the next meeting was reviewed.



Recommended Practice for AI-ESTATE

The intent is to focus on user-guide types of issues. Usability is a big issue with AI-ESTATE, and some kind of document to help people would be extremely valuable. It was put on the agenda for the next meeting. The focus will start with the requirements document, and then a PAR will be put together.



The meeting adjourned at 10:47.

Attendees

Name

Affiliation

Email

Day 1

Day 2

Day 3

Alwardt, Tony

Boeing

anthony.l.alwardt@boeing.com

X

X


Busch, Darryl

Honeywell

darryl.busch@honeywell.com

X

X

X

Chun, Kahn

USMC TMDE

khan.chun@usmc.mil

X

X


Esen, Erol

Impact Technologies

erol.esen@impact-tek.com

X

X

X

Fandino, Oscar

Lockheed-Martin

oscar.fandino@lmco.com


X


Gerstein, Bill

Hamilton Sundstrand

we.gerstein@hs.utc.com

X

X

X

Harris, Michelle

Lockheed-Martin

michelle.l.harris@lmco.com

X

X


Helton, Alicia

Lockheed-Martin

alicia.helton@lmco.com

X

X

X

Jimmerson, Carey

AMRDEC

carey.jimmerson@amrdec.army.mil

X

X

X

Kalgren, Pat

Impact Technologies

patrick.kalgren@impact-tek.com


X

X

Modi, Mukund

NAVAIR

mukund.modi@navy.mil

X

X

X

Ralph, John

Northrop Grumman

john.ralph@ngc.com

X

X

X

Seavey, Mike

Northrop Grumman

michael.seavey@ngc.com


X


Sharone, David

Lockheed-Martin

david.sharone@lmco.com


X


Sheppard, John

Johns Hopkins University

jsheppa2@jhu.edu

X

X

X

Stanco, Joe

SSAI

jstanco@ssai.org

X

X

X

Wilmering, Wilmering

Boeing

timothy.j.wilmering@boeing.com

X

X

X


Action Item Summary

Old Action Items

New Action Items


Open Issues

Items Logged at 08-A Meeting

Items Logged at 08-B Meeting

Proposed 08-C Agenda