[Moims-dai] Fwd: IPELTU Annex D - DPOP Checklist

Mon Apr 15 13:47:03 UTC 2019

FYI. I received the following message and attachment from Kjell Bengtsson.
I thought this might be of interest to the DAI Working Group.

Mark

---------- Forwarded message ---------
From: Kjell Bengtsson <Kjell.Bengtsson at jotne.com>
Date: Sat, Apr 13, 2019 at 3:55 AM
Subject: RE: [Moims-dai] IPELTU Annex D - DPOP Checklist
To: Mark Conrad <mark.conrad at nara.gov>

Hi Mark,

Thanks for the checklist.

I was wondering if you have a further details on these two points?  You
know me, I would like to see that you specify ISO 10303 to meet these
objectives, but how do you preserve this data today?

þ

Spacecraft Engineering Data

þ

Test Article Engineering Data

As enclosed, some ideas on how to manage CAD/PLM/Simulation and test data
using ISO 10303.

Best regards, Kjell

*From:* Mark Conrad [mailto:mark.conrad at nara.gov]
*Sent:* fredag 12. april 2019 20.35
*To:* MOIMS-Data Archive Interoperability <moims-dai at mailman.ccsds.org>
*Subject:* Re: [Moims-dai] IPELTU Annex D - DPOP Checklist

Mike,

Thanks for putting this together. Overall it looks very good. I have
attached a version with my comments. I have also attached a records
disposition schedule from NASA that lists some of the types of records that
need to be retained. See especially Item 1 and Note 1. I hope this
information is helpful.

Mark Conrad
NARA Information Services

Systems Engineering Division (IT)
The National Archives and Records Administration
Erma Ora Byrd Conference and Learning Center
Building 494, Room 225
610 State Route 956
Rocket Center, WV  26726

Phone: 304-726-7820
Fax: 304-726-7802
Email: mark.conrad at nara.gov

On Thu, Apr 11, 2019 at 6:39 PM Mike Kearney <kearneysolutions at gmail.com>
wrote:

DIA WG colleagues:  In the telecon on Tuesday 4/9, we discussed my draft
Annex D for IPELTU.  For those that weren’t there, my original action was
to develop an annex to instruct space *operations* teams what data should
be preserved.  I have expanded that to be an annex for spaceflight
*programs/projects
as a whole*, on the premise that at the beginning of a project we need for
the top-level program/project manager to dictate to the rest of the team
what will or will not be preserved, from his mission, in the long term.  So
it’s no longer just operations, it’s the whole mission.  The checklist
makes some pointed statements that should get the attention of management,
about what results of his project are worth preserving in the long run.  In
this way, it encourages early (pre-phase A?) planning and recognition that
resources should be allocated for preservation.

I’ve coined the phrase DPOP (Digital Preservation Objectives Proforma)
Checklist.  After some discussion, we discarded similar terms to PICS- and
ICS-Proforma to avoid any implication of “compliance” guidance.  Some
discussion on “Proforma” is in the first page instructions.  The single
word version (proforma vs. pro forma) is used for compatibility with other
CCSDS usage.

While this one is for space missions, I envision other DPOP Checklists as
annexes for other types of endeavors.  Manufacturing, academia,
oceaneering, information technology development, etc.  CCSDS does space
missions, but other disciplines can be invited to create DPOP Checklists
for their industry.

So, this is a very rough draft.  Steve Hughes has agreed to try to expand
section 1.5 with the experience of PDS, but of course other contributors
and other comments are welcome.

Here are a few notes:

·         I think it’s important to keep the first page instructions
limited to one page.  If it’s too long, it won’t be read or used.  It has
to be something a manager can pick up and start checking/revising quickly.

·         For Level 0, 1 and 2 processing guidance, I used this website:
http://www.srl.caltech.edu/ACE/ASC/level1/dpl_def.htm  Of course, different
missions will have different terminology, so I reflected that in the
first-page instructions.

·         My intention in the check boxes is that this should be made
available in Word format (perhaps from SANA) for managers to easily capture
and modify for their program.

·         Two levels of detail are represented.  High level for the
managers that want only 10 or so items to check off, and let the lower
level teams interpret it.  Detailed level (just barely begun) for the
managers that understand what needs to be preserved, and want to manage the
resources needed to preserve it.

For discussion online and at Mountain View.

   -=- Mike

Mike Kearney

Huntsville, Alabama, USA

_______________________________________________
MOIMS-DAI mailing list
MOIMS-DAI at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20190415/b3087c5c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Relating structural test and FEA data with STEP AP209_official.pdf
Type: application/pdf
Size: 2471461 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20190415/b3087c5c/attachment-0001.pdf>