Electronic Work Instruction Management System (EWIMS)

Development of a Proof-Of-Concept Work Instruction Management System (WIMS) for NASA's ATF KMS

Background

This document describes the work to be performed for a software pilot project at the NASA Glenn Research Center’s (GRC) Neil A. Armstrong Test Facility (ATF) in Sandusky, OH. The goal of this software pilot project is to show how the existing Mediawiki-based Knowledge Management System (KMS) at GRC-ATF can be enhanced to facilitate a transition from a paper-based work instruction performance process to an all-electronic (and specifically all-mediawiki-based) implementation of the existing work instruction development and execution processes. This pilot project requires the conversion of four (4) of NASA's existing Microsoft Word-based work instructions into the Mediawiki-based format and a demonstration that they can be successfully developed and executed entirely within the ATF KMS system using enhancements to be determined.

Scope of Work

All activities required to develop and test an all electronic wiki-based work instruction system that meets these requirements.

Milestone planning

Milestone	Expected Duration	Corresponding Date
Project Start	*	Nov. 15th, 2021
First release of the developed WIMS available for review and inspection by test	120 hours	Dec. 3rd, 2021
WIMS accepted and approved for integration into the existing NASA GRC ATF KMS	120 hours	Dec. 24th, 2021

Definitions

Term	Definition
GRC ATF	NASA Glenn Research Center's Armstrong Test Facility in Sandusky, Ohio
ATF KMS	The Mediawiki-based Knowledge Management System at ATF
WIMS	The 100% wiki-based "Work Instruction Management System"
WIMS Work Instruction Pages	A class of pages generated in the ATF KMS by the WIMS that corresponds to an individual Work Instruction article that is defined, revised, and released in accordance with the procedure in Chapter 4 of NASA's GLP-H-8830.2 Rev E
WIMS As-Run Instance Pages	A class of page generated in the ATF KMS by the WIMS that corresponds to a wiki page that is an instance of a WIMS Work Instruction that can be authorized, performed, and archived in accordance with the procedure in Chapter 5 of NASA's GLP-H-8830.2 Rev E

Applicable Documents

Document ID	Document Title	Revision	Date
NASA GLP-H-8830.2	ATF KMS Managed Work Instruction Development and Execution	E (Draft)	2021-10-19

Reference Documents

Document ID	Document Title	Hazardous/Non-hazardous	Revision	Date
NASA GRC-ATF PBISP-037	Chamber Top Cap Operation	Non-hazardous	2	2017-05-16
NASA GRC-ATF PBISP-043	Spray Chamber Personnel Entry	Hazardous	6	2017-05-02
NASA GRC-ATF PBSPF-029	Low Oxygen Monitoring System	Non-hazardous	2	2015-12-23
NASA GRC-ATF PBSPF-229	VTC Low Oxygen Monitoring	Non-hazardous	1	2017-06-29

Requirements

1.0	Architecture Requirements
#	Requirement	Rationale
1.1	Mediawiki Version - The WIMS shall be able to be implemented entirely on the existing ATF KMS Server running MediaWiki 1.34.4	Rationale: The ATF KMS is currently using a custom 34.x branch of Meza [1] [1] https://www.mediawiki.org/wiki/Meza
1.2	No loss of existing functionality - The WIMS shall not result in the loss of any existing functionality of the ATF KMS	Rationale: Many features of the ATF KMS that are not presently relevant to the WIMS project are essential to other capabilities of the ATF KMS.
1.3	Extension Criteria - The WIMS shall only introduce new extensions that are from well-established developers and maintainers and have an existing list of enterprise users	Rationale: NASA seeks to minimize the likelihood of becoming critically dependent on an extension that is not actively supported by the MediaWiki community.
1.4	WIMS Implementation Page Categories - All wiki pages created by the pilot project relating to the implementation of the WIMS requirements (i.e. Forms, Templates, Properties, Dashboards, etc..) shall be added to a MediaWiki category named "Tool - WIMS"	Rationale - It is necessary to be able to identify all pages that are part of the WIMS project
1.5	WIMS User Content Page Categories - All wiki pages generated by the WIMS shall be added to Mediawiki categories according to their type (Work Instruction, As-Run Instance, Deviation, Step Performed, etc..).	Rationale - It is necessary to be able to identify all pages that are generated by the WIMS project based on what they are to the WIMS.
2.0	Work Instruction Requirements
#	Requirement	Rationale
2.1	Define Work Instructions - The WIMS shall enable users to define Work Instructions in the WIMS in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - Users need to be able to generate and maintain the list of work instructions as data in the WIMS.
2.2	Develop Revisions of Work Instructions - The WIMS shall enable users to develop work instructions in the WIMS as wiki articles in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - Users need to be able to develop revisions of work instructions in the WIMS that can be released and performed.
2.3	Release Revisions of Work Instructions - .The WIMS shall allow users to release revisions of defined and developed work instructions to be performed multiple times.	Rationale - User should only get the latest approved revision of a work instruction.
2.4	Generate As-Run Instances - The WIMS shall be able to generate an "As-Run" instance of "released" revisions of Work Instructions	Rationale - It is one of the primary goals of the WIMS to provide a wiki-based system that allows users to perform work instructions multiple times.
2.5	Semantically Queryable properties of the WIMS - The WIMS shall make the following aspects of work instructions available as semantically queryable properties: Work Instructions Revisions: Title Revision Revision Date Owner Approving Signatories As-Run Instance Pages of Work Instructions: Work Instruction Revision based on Creation date Approval to Proceed data Section Start Approval data Section Completion data Step performance data (who and when, and value when applicable) Per-Step Deviation text (when supplied) Per-Step Deviation Authorization status	Rationale - It is one of the primary goals of the WIMS to provide a wiki-based system that allows users to search, list and organize work instructions and all as-run instances of work-instructions as queryable semantic data.
2.6	Track As-Run Instances - The WIMS shall be able to track the existence and status of each As-Run instance of a work instruction that is performed.	Rationale - It is one of the primary goals of the WIMS to provide a wiki-based system that allows users to track the when work instructions are performed and what the status is.
2.7	As-Run Certification of the Document - The WIMS As-Run Instance Pages shall be capable of displaying the "Certification of the Document" information of which it is an instance in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - performers need to be able to verify that the As-Run instance they are using is the latest authorized version of the work instruction.
2.8	As-Run "Approval to Proceed" - The WIMS As-Run Instance Pages shall be capable of allowing users to fill out the "Approval to Proceed" section of the work instruction in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - performers need to be able to verify that the As-Run instance they are performing has been authorized to be performed.
2.9	As-Run "Section Start Approval" - For WIMS As-Run Instance Pages that are approved to proceed, the WIMS As-Run Instance Pages shall be capable of allowing users to fill out the "Section Start Approval" page in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - performers need to be able to verify that the sections of the As-Run instance they are performing are authorized to be performed.
2.10	As-Run "Section Completion" - For WIMS As-Run Instance Pages that have sections to perform indicated, the WIMS As-Run Instance Pages shall be capable of allowing users to indicate completion of a section in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - performers need to be able to indicate when a section has been completed.
2.11	As-Run "Indication of Step Performance" Traceability - The WIMS As-Run Instance Pages shall be capable of having steps defined where the performer is required to indicate completion of the step in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - It is common that procedures require the performer to indicate completion of the step.
2.12	As-Run "Indication of Step Performance with Field Input" Traceability - The WIMS As-Run Instance Pages shall be capable of having steps defined where the performer is required to supply an alphanumeric data value at the time of performance as a prerequisite to being able to indicate completion of the step in accordance with NASA GRC-H-8830.2 Rev E.	Rationale - Sometimes procedures require the performer to capture data as part of the execution of the step.
3.0	As-Run Step Deviation Requirements
#	Requirement Text	Rationale
3.1	Per-step deviation state - For all steps, the WIMS shall track the deviation status of each step as being in one of the following 3 states: No deviation Unconfirmed deviation Confirmed deviation	Rationale - the system needs to know the deviation state of every step in order to ensure correct performance of the work instruction.
3.2	Defining deviations - For all steps, the WIMS shall allow users to create and edit deviation text for any step that has not been indicated as performed.	Rationale - Sometimes performers must deviate from the written procedure and need a way to capture the scope and details of the deviation.
3.3	Effect of editing deviations - For all steps, the WIMS shall set the deviation status any step to "Unconfirmed deviation" upon the creation or updating of deviation text for that step	Rationale - We can't allow steps to be performed with unconfirmed deviation text.
3.4	Required states for step performance - For all steps, the WIMS shall only allow users to indicate performance of a step that is in the "No deviation" or "Confirmed deviation" state.	Rationale - We can't allow steps to be performed with unconfirmed deviation text.
3.5	Confirmation of deviation text - For steps with deviation text, the WIMS shall require a user to manually set the deviation status to "Confirmed deviation".	Rationale - When deviations occur, it is essential to provide a way for the deviation to be approved separately from the act of authoring the deviation text

Government Furnished Equipment

1. NASA Document GRC-H-8830.2 Rev E - NASA will provide the project with an electronic copy of ATF's internal ISO procedure for developing and executing work instructions: GLP-H-8830.2 Rev E. This document will provide the project with a complete specification of all aspects of developing and executing work instructions at ATF.
2. VirtualBox image file of the current ATF KMS wiki server - NASA will provide the project with a single ISO image file that can be booted from Oracle's Virtual Box virtual machine software. The image file will be a completely functional and stand-alone version of the NASA KM Wiki Server that the project can use as the starting point for the deliverables
3. Software Version Description of the ATF KMS from the VirtualBox image file of the NASA ATF KMS provided.
4. Four (4) MS Word-based ATF Work Instructions Files - See Reference Documents Section

Project Deliverables

1. VirtualBox image file of an upgraded NASA KM Server with WIMS capability - The project will provide NASA with a single ISO image file that can booted from Oracle's Virtual Box virtual machine software. The image file will be a completely functional and stand-alone version of the NASA KM Project that the project shall use as the starting point for the deliverable
2. Verification by Demonstration of all project requirements - The project shall provide a demonstration to NASA to verify that all of the requirements of the project are met.
3. Document describing any changes that were made the ATF KMS Server - The project shall provide NASA with a document that describes any intentional changes that were made to the ATF KMS server during the work of the project. This document shall include the following sections:
   1. Server enhancements
      1. packages updated
      2. packages added
      3. package configurations created or modified
   2. Mediawiki enhancements
      1. extensions updated
      2. extensions added
      3. extension configurations created of modified
      4. any modifications to the core configuration
   3. Forms, Templates, Categories, Properties
      1. New Forms, Templates, Categories, Properties
      2. Modified Forms, Templates, Categories, Properties
   4. Main namespace content
      1. New Main namespace content
      2. Modified Main namespace content
   5. All other wiki content

Phase 1 Verification

#	Requirement text	Implementation in Stand-alone WIMS	Implementation comment	NASA Response
1	Architecture Requirements
1.1	Mediawiki Version	Will be a Stand-alone wiki running MediaWiki 1.35.x	See https://wims.wikibase.nl/	Accept
1.2	No loss of existing functionality	Stand-alone, so not integrated with ATF KMS		Concur
1.3	Extension Criteria	Possibly an extension will be needed for the as-run instances to work smoothely.	No new extensions were created for WIMS specifically, but it does use extensions that are included in Open CSP. Also there is some JS and CSS that has now been added to MediaWiki:Common.css/js, which could be added to an extension later	All extensions and add-ons listed in the WIMS Special:Version page need to have links to mw.o extension pages with links to code repos accessible to the public
1.4	WIMS Implementation Page Categories	Yes, or identifiable in other practical way.	The pages are marked using Template:Wims page, which sets the property Class="ocspwi module page"	Accept and ask why Categories are not used
1.5	WIMS User Content Page Categories	Yes, or identifiable in other practical way.	User content has the Class property with values "Work instruction draft", "Published work instruction", "Run work instruction", "Work instruction deviation". To be discussed: how to deal with images that are uploaded through VE in Work instruction drafts or deviations? NASA has a solution which they can share	NASA recommends using the SimpleBatchUpload Extension [1] and taking advanatge of the "add prefix to upload filename" option and use a gloablly set variable (like WIMS) and the page ID to create a filename prefix that is guaranteed to be unique for the page it is being uploaded to (i.e. the Procedure) [1] https://www.mediawiki.org/wiki/Extension:SimpleBatchUpload
2	Work Instruction Requirements
2.1	Define Work Instructions	Users will be able to generate and maintain the list of work instructions as data in the WIMS. Uncertain whether fully in accordance with GRC-H-8830.2 Rev E requirements.	To create a new work instruction go to Draft Work Instructions and create a new draft. From there you will have the option to publish a new revision.	Accept
2.2	Develop Revisions of Work Instructions	Work instructions can be created, edited, reviewed and released.	Draft work instructions can be edited. A draft can be released by publishing a new revision.	Accept
2.3	Release Revisions of Work Instructions	On approval, work instructions are copied to a separate namespace that only contains approved work instructions.	Draft work instructions are in the "Draft" namespace, published revisions are in the "Published" namespace and run instances and deviations are in the "Run" namespace.	Obsolete revisions or revisions superceeded by newer revisions must not be available to run
2.4	Generate As-Run Instances	Yes	Can be created from a published work instruction	Accept
2.5	Semantically Queryable properties of the WIMS	Yes	Yes, the most important properties are Class, ID, Revision number, Revision tweak, Revision (a combination of number and tweak), Title. New ones can be added.	Unclear - need to see scratch query examples of: 1) Steps performed in Run Instance X of proc Y 2) Steps not performed in Run Instance X of proc Y
2.6	Track As-Run Instances	Yes	A published work instruction shows a list of as-run instances created from that work instruction.	Accept
2.7	As-Run Certification of the Document	No, only after integration with ATF KMS.		Concur
2.8	As-Run "Approval to Proceed"	Yes	Creating a run instance is considered to be the approval to proceed	Not acceptable - the authorization to proceed section is a critical aspect of our work instruction execution process which is well defined and well-documented in our 8830.2 Rev E  document
2.9	As-Run "Section Start Approval"	Yes	The "Work instruction section approval" template can be inserted in a draft and will show an approve button in run instances	Accept
2.1	As-Run "Section Completion"	Yes	The "Work instruction section approval" template will show a complete button after the section has been approved	Request that both the start and completion approvals are both maintained independantly - as it is right now 'complete' replaces 'start' and we need to see both.
2.11	As-Run "Indication of Step Performance" Traceability	Yes	Changes are stored in a separate parameter for each input field. These values are stored in a slot. See "Tools" > "Slots" to view slot values. The templates currently don't display these values anywhere.	Our ISO process requires that auditors be able to see who performed each step .. And per 2.5 above all of the "as-run step performance" data needs to be queriable properties.. Once 2.5 is fulfilled, displaying data relating to the step performance should be straight-forward
2.12	As-Run "Indication of Step Performance with Field Input" Traceability	Yes	See 2.11	See 2.11 response
3	As-Run Step Deviation Requirements
3.1	Per-step deviation state	Yes	The steps show when they have a deviation through changing the color of the icon	Our ISO process requires that auditors be able to see any deviations in the as-run copy. Having to click a link to see the deviation in a new page is ok for collecting the deviation text, but the deviation text needs to appear in the as-run document
3.2	Defining deviations	Yes	Deviations can be added to each step through the "!" icon. They can also be edited.	If deviations are going to be captured in a sepereate page, then the deviation page needs to include more context in order for users writing and reviewing the deviation to undertand the deviation text (not just a cryptic reference to a step id. This should include at a minimum, WI ID, WI Title, WI Revision, As-Run Creation Date, and As-Run Page ID
3.3	Effect of editing deviations	Yes	To be discussed	As stated in the requirement - For all steps, the WIMS shall set the deviation status any step to "Unconfirmed deviation" upon the creation or updating of deviation text for that step
3.4	Required states for step performance	Yes	To be discussed	As stated in the requirement - For all steps, the WIMS shall only allow users to indicate performance of a step that is in the "No deviation" or "Confirmed deviation" state.
3.5	Confirmation of deviation text	Yes	To be discussed notes from meeting 14 jan: when creating a new deviation it should initially be "unconfirmed". Multiple users should be able to confirm a deviation (for example by clicking a button on the deviation page). After the first confirmation, the deviation should not be editable. There should be some kind of visual indication of the confirmation status in the run work instruction (perhaps change the icon color), also when we deviation is added after the step completion.	Notes from meeting 14 jan to be implemented in accordance with stated requirmeents for 3.2 through 3.5
Other Notes
				some checkboxes don't ever display a green notification
				request that check boxes immediately notify that they are working on something - rather than wait for the Saved Successfully popup
				signatory name, date and time need to be captured and displayed (when they have been provided) as data - currently signature, date and time fields are not able to be captured  via the wiki
				nasa needs to provide a signatory input requirement
				in lieu of a proper signatory input type, the work instructions need to be updated to include at least basic text entry fields for signatories and date and time
				input text fields need to indicate when they are performed as empty - possibly enable/disable