Developing Data-Input Standards for Computerized Maintenance Management Systems: Summary of a Symposium/Workshop (1994)

Paul Fardig and William Brodt

U.S. Public Health Service

Operation and maintenance information for building equipment generally is provided by manufacturers in paper-based manuals. These manuals are often unavailable when needed, either being misplaced or lost, or stored in a central archive, away from the equipment and maintenance personnel. Consequently, many building owners and facility managers ask for additional copies of manuals, forge ahead with “seat of the pants” maintenance, or skip preventive maintenance altogether and flounder about blindly when troubleshooting a problem.

Computerized Maintenance Management Systems (CMMS) have been developed to overcome some of these problems by gathering operation and maintenance information together into a unified data library which can be made available throughout an organization via networked computer terminals. CMMS also automate scheduling and tracking of maintenance activities, resulting in more effective use of resources.

However, manually entering operation and maintenance data for each piece of building equipment into CMMSs is error prone and very costly. Consequently, many locations that could benefit from CMMSs do not. In these cases maintenance is performed less efficiently, equipment breaks down more frequently, and manufacturers' reputations suffer unnecessarily.

Manufacturers already have and provide the necessary information to building owners. What is needed is this same information in a standardized format so that CMMS software can automatically read it and add it to their unified data library.

A standard, but flexible, electronic format for operation and maintenance data is described below. This LEVEL ONE standard is sufficiently simple that virtually all manufacturers can achieve it without difficulty and at negligible cost. A limited

number of simple procedural rules for embedded codes are defined. These rules and codes can be used by anyone familiar with basic word processing software.

The standard format will benefit manufacturers by improving maintenance procedures and henceforth reliability of their products, and benefit building owners and software developers by increasing the number of facilities that will find maintenance management software cost effective.

A more advanced solution, based on developments in the DoD Computer-aided Acquisition and Logistic Support (CALS) program, is anticipated as the future format for electronic maintenance data input. The CALS program is developing electronic representations of technical documentation in both traditional and interactive forms. The developments are based on several international data standards, including the Standard Generalized Markup Language (SGML) and the Standard for the Exchange of Product Model Data (STEP). Not all the technical pieces are in place in the CALS program yet. The Level One standardization effort proposed in this document will be planned so that a smooth transition can take place when the CALS program is complete.

The primary data exchange will be on floppy disks for MS-DOS based personal computers. MS-DOS based personal computers are ubiquitous in business settings, even in the smallest of companies. Most other systems (e.g., minis and mainframes) already have or can readily develop a simple way to translate from this standardized format. Also, all third party technical writing organizations can prepare information in MS-DOS format.

Floppy disks will accompany the operations and maintenance manual provided by the manufacturer at the time of purchase (replacing one or more paper copies).

Other data exchange media such as CD-ROM and electronic bulletin boards are logical extended applications of the data exchange concept, but are not included in this initial LEVEL ONE standardization effort.

Operation and maintenance information will be provided in an electronic master file, with associated graphic and database files, and an optional menu file.

Basically, the master file is the current instruction manual in straight ASCII format, with header information and links to graphics and/or database tables, if any, designated according to the procedural rules below. Virtually all MS-DOS based word processing programs can either produce ASCII files directly or convert their word processing documents to the ASCII format. All information (except the optional menu file) is linked through the single master ASCII file.

Four types of embedded codes are defined by the procedural rules: warning, navigation, predefined external file formats, and executable external files. Each embedded code starts with two “@” characters at the far left edge of a line of ASCII text (i.e., following a line feed/carriage return character) and continues until an additional two adjacent “&” characters are encountered on the same line (i.e., before encountering another line feed/carriage return character). For clarity and consistency, there should be nothing but the rule on the line, and the lines above and below the code should be left blank. If there is not a closing set of “@” characters on the line, the code is ignored (i.e., a line feed/carriage return is encountered before the second set of “@” characters).

Background: Paper manuals frequently will display warnings in bold or enlarged type, or even reversed (white on a black background). These characteristics are not available in a LEVEL ONE straight ASCII file. However, by placing warning text between embedded codes, appropriate software can display it differently from the main text, thereby attracting the user's attention to the warning.

Manufacturer Requirements: Insert warning messages between warning embedded codes as indicated below. Optionally, warning text between the embedded codes may be right and left indented and/or enclosed within an ASCII line drawing box to further draw attention to it.

Developer Requirements: CMMS software shall read embedded warning codes and display the enclosed text in a warning color. Even if only a part of the warning message is displayed on a particular screen, it shall be in the warning color. Default warning color shall be white on a red background for color monitors, and reversed for monochrome monitors.

Embedded Code Use:

@@WARNING:@@

text of warning message displayed in special color within the body of the general text - standard warning would be white on red

@@ENDWARN:@@

Backgound: Navigating through an electronic document is different than moving from chapter to chapter in a conventional manual. Visual and physical clues denoting where the user is within the document are limited, so it is very important to provide navigational indicators. By placing the current Chapter (and Section and Subsection, as appropriate) in the embedded code, appropriate software can display that information on the top line of the screen, so the user can see where he/she is, even as the main text scrolls from line to line.

A hierarchy of navigational indicators can be established by indicating a number, 1 through 9, following the “@@NAV” initiation of the embedded command. For example, chapter headings, which are the main organizational groupings, would start “@@NAV1,” main section headings, “@@NAV2,” subsection headings, “@@NAV3,” etc. See examples below.

Software developers could create document maps (outlines or Tables of Contents) from the navigational indicators. These maps would be used to allow users to jump rapidly from one Chapter or Section to another.

Manufacturer Requirements: Insert navigational information in embedded codes as indicated below. Create a hierarchy of Chapter/Section/Subsection information by indicating a number 1 through 9 in the embedded code.

Developer Requirements: CMMS software shall read parameters in navigational embedded codes and display the corresponding navigational information on the screen, even as the main body of the text scrolls.

CMMS software shall create a document map or Table of Contents from the navigational codes, to a user specified level of detail (e.g., 2 or 3). The user should be able to hotkey, mouse pick, or otherwise activate the map and be able to jump to a selection from the map list.

e.g.,

@@NAV1: TROUBLESHOOTING@@

here regular introductory text for Chapter: TROUBLESHOOTING

@@NAV2: TROUBLESHOOTING - INDICATOR LIGHTS@@

regular text on Indicator Lights topic under Chapter: TROUBLESHOOTING

@@NAV1: OPERATIONS@@

now regular introductory text for Chapter: OPERATIONS

Background: Manuals generally contain graphs, drawings, photographs, charts, database table, and similar entities. Most of these cannot be effectively represented in a LEVEL ONE straight ASCII file. A way is needed to be able to jump to the display of such entities at the appropriate place in the master file text. By placing an embedded code identifying the file name and format with the graph or similar entity, it can be retrieved and displayed at the appropriate time through a hotkey or mouse pick.

Manufacturer Requirements: Save graphs, drawings, and similar entities as separate files, in one of the predefined external file formats. Insert proper embedded code at the appropriate place within the master file.

Developer Requirements: CMMS software shall read parameters in embedded predefined files codes as user scrolls through the master file. Software shall define a hotkey or mouse pick to activate the display of the currently active file through an appropriate viewer.

CMMS software shall create a figures (and executable files, see below) map from the embedded predefined file codes. The user should be able to hotkey, mouse pick, or otherwise activate the map and be able to display a selection from the map list.

(optionally can pass parameter to filename) - @@TXT:filename parameter@@

Background: Electronic media allow suspending an active program to run another program, then returning to the original program. For example, an artificial intelligence troubleshooting program could be created for a particular piece of equipment. A way is needed to be able to call up such entities at the appropriate place in the master file text. By placing an embedded code identifying the file name of a MS-DOS executable file, it can be activated at the appropriate time through a hotkey or mouse pick.

Manufacturing Requirements:(OPTIONAL)Developindependent,stand-alone MS-DOS executable files for special functions such as a troubleshooting expert system. Insert proper embedded code at the appropriate place within the master file.

Developer Requirements: CMMS software shall read parameters in embedded executable external file codes as user scrolls through the master file. Software shall define a hotkey or mouse pick to activate the externally executable file.

CMMS software shall create a figures and executable files map from the embedded codes. The user should be able to hotkey, mouse pick, or otherwise activate the map and be able to display or execute a selection from the map list.

@@EXE:filename plus optional parameters@@

hotkey will shell to DOS and run filename, for example, artificial intelligence diagnostic troubleshooting software. The “.EXE” parameter will not be passed to MS-DOS, so could also run .COM or .BAT file. optionally, one or more parameters listed on the command line would also be passed to the executable file.

e.g.,

@@EXE:TRBLSHOO PART1234@@

the DOS file “TRBLSHOT” would be executed, with the parameter “PART1234” passed to it. More than one parameter could be passed, up to the DOS line length limit.

Maintenance Schedule (define std DOS names-with formal data dictionary) activity level number (used to link with parts list)

when a maintenance activity is scheduled, program can produce list of required parts, by extracting from parts list all parts with equal or lower activity level numbers. (e.g., number 1 would be most frequent activity; number 2 would be assumed to include all of number 1 activities as well)

Parts List

part description

manufacturer's number

manufacturer

activity level number (link to maintenance schedule)

view file name (@@DXF:explodia 12456@@)

Index File (OPTIONAL - user or developer modifiable) index term or terms (will be sorted alphabetically) chapter/subchapter in main text file which contains term

(@@NAV2:TROUBLESHOOTING-INDICATOR LIGHTS)

Menu File (OPTIONAL - user or developer modifiable)

(items in a menu callable from the main text file) menu choice

menu description (displayed when menu choice is highlighted)

Y/N if hotkey should be activated automatically when choice is selected from menu

search string to locate within main file

e.g.,

Manufacturers may provide a PopUp Menu which would include basic functions required to operate within the maintenance text file, such as displayed below:

Developer may automatically incorporate menu items provided by manufacturer in the “Menu” database file. OR - developer or user could insert items within the data base file

Menu would have ability to wrap further if too many choices for one line.

The first 9 menu items may be standardized, such as:

Then add manufacturer's menu items.

The default key to display the menu should be standardized, e.g., <F10>

The default hotkey to display the currently active shell activity should be standardized, e.g., <SHIFT-F10>

hotkey to related file/figure indicated by currently active “@@”
resizeable hotkey window --- F3 to display previous figure,
F4 to display next.

hotkey to navigation or command line (need separate nav/com lines ??) from navigation/command line, jump to special topics such as:

(categories will be listed in Index file)

table of contents (generated from @@NAVx: in main file) different levels would be possible

troubleshooting

parts list

schematics - exploded diagrams

preventive maintenance schedule

operations

search for text

bookmarks/placemarks

redline/grayout editing

select and print (to printer or file) block of text

line number of main file

mouse support

equipment name displayed

help screens.