Items in cart [0] Questions? Call 888-624-8373

Rights & Permissions Free Resources Display this book on your site! Related Titles Space Studies Board Annual Report 2003 Patient Safety: Achieving a New Standard for Care Other Related Titles Developing Data-Input Standards for Computerized Maintenance Management Systems: Summary of a Symposium/Workshop (1994) Federal Facilities Council (FFC) Web Search Builder Use this book's key terms to search within this book, across our collection, or across the Web. Skim This Chapter Skim this chapter and use this chapter's key terms to search within this book. Reference Finder Paste in your own text to find books that relate to your topic. Page 26   E-mail  Facebook  Digg  Stumble  Twitter More The following HTML text is provided to enhance online readability. Many aspects of typography translate only awkwardly to HTML. Please use the page image as the authoritative form to ensure accuracy. PROPOSED ELECTRONIC MAINTENANCE DATA INPUT STANDARDS - LEVEL ONE Paul Fardig and William Brodt U.S. Public Health Service PROBLEM: 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. PROPOSED SOLUTION: 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 Page 26 FRONT MATTER (R1-R6) CONTENTS (R7-R8) HOW IT COULD BE - A PROPOSAL AND A VISION (1-5) AN OWNER'S PERSPECTIVE (6-14) A MANUFACTURER'S PERSPECTIVE (15-17) HOW THE CMMS STANDARDS EFFORT WOULD BE CARRIED OUT BY ASTM (18-20) CMMS VENDOR'S PERSPECTIVE (21-25) PROPOSED ELECTRONIC MAINTENANCE DATA INPUT STANDARDS - LEVEL ONE (26-34)

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 26
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) PROPOSED ELECTRONIC MAINTENANCE DATA INPUT STANDARDS - LEVEL ONE Paul Fardig and William Brodt U.S. Public Health Service PROBLEM: 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. PROPOSED SOLUTION: 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

OCR for page 27
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) 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. ASSUMPTIONS: 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. PROPOSED STANDARD - LEVEL ONE: Operation and maintenance information will be provided in an electronic master file, with associated graphic and database files, and an optional menu file. MASTER 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.

OCR for page 28
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) GENERAL PROCEDURAL RULES: 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). PROCEDURAL RULES AND CODES FOR WARNINGS: 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:@@

OCR for page 29
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) PROCEDURAL RULES AND CODES FOR NAVIGATION INFORMATION: 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. EMBEDDED CODE USE: @@NAVx:navigational label@@ The “x” will indicate different levels (not different chapters) of a map or Table of Contents outline. If no “x” value is present, it will not be included at any level of mapping, but will display as navigational label when activate. e.g., @@NAV1: TROUBLESHOOTING@@ here regular introductory text for Chapter: TROUBLESHOOTING

OCR for page 30
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) @@NAV2: TROUBLESHOOTING - INDICATOR LIGHTS@@ regular text on Indicator Lights topic under Chapter: TROUBLESHOOTING @@NAV1: OPERATIONS@@ now regular introductory text for Chapter: OPERATIONS PROCEDURAL RULES AND CODES TO LINK TO PREDEFINED EXTERNAL FILES: 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. EMBEDDED CODE USE: @@TIF:filename@@ hotkey will shift to TIF file displayer, and display the filename indicated (for bit mapped images) @@DXF:filename@@ hotkey will shift to DXF file displayer, and display the filename indicated. (for vector based images) @@DBF:filename@@ hotkey will shift to DBF file displayer, and display the filename indicated. (for data base tables) @@txt:filename@@ hotkey will shift to TXT file displayer, and display the filename indicated. (for ASCII text subsets) (optionally can pass parameter to filename) - @@TXT:filename parameter@@

OCR for page 31
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) PROCEDURAL RULES AND CODES TO LINK TO EXECUTABLE EXTERNAL FILES: 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. EMBEDDED CODE USE: @@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. SEPARATE DATABASE FILES PROVIDED BY MANUFACTURER Maintenance Schedule (define std DOS names-with formal data dictionary) activity level number (used to link with parts list)

OCR for page 32
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) 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) activity title prime frequency number e.g., (1,000) prime frequency units (operating hours) alternative frequency number (6) alternative frequency units (calendar months) activities to be performed link to external file with text description - include activity level number parameter e.g., @@txt:maintfil 3@@ 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., TShoot Troubleshooting guide Y @@EXE:TSHOOT@@ Maint Preventive maintenance Schedule Y @@DBF:PMAINT@@ Parts Parts list Y @@DBF:PARTSLST@@ Ops Operations guide N @@NAV1:OPERATIONS@@

OCR for page 33
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) Specs Specifications N NAV1:SPECIFICATIONS@@ Install Installation instructions N @@NAV1:INSTALLATION@@ SUGGESTED USE OF DATABASE FILES BY SOFTWARE DEVELOPERS 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 eXit Help GoTo Key Find BM +BM -BM TShoot Maint Parts Ops Specs Install Menu would have ability to wrap further if too many choices for one line. The first 9 menu items may be standardized, such as: eXit − leave program Help − displays help information by developer GoTo − brings up submenus, including table of contents created from @@NAVx lines and list of figures/executables from other @@ display/execute lines also,: jump to line number and option to change NAVx level displayed. Key − hotkey toggles to currently active shell activity Find − requests text string to find, not case sensitive Edit − brings up editing submenu grayout toggle redline editing BM − toggles book mark, if on line with bookmark, erases it; otherwise sets a mark +BM − zooms to the next book mark (NOTE): the equals sign “=” should also activate this choice, it is the lower case symbol on the same physical key as the “+” sign on the main keyboard. −BM − zooms to the previous book mark 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>

OCR for page 34
DEVELOPING DATA-INPUT STANDARDS FOR COMPUTERIZED MAINTENANCE MANAGEMENT SYSTEMS: (Summary of a Symposium/Workshop) EXAMPLE OF POSSIBLE PROGRAMMING FEATURES 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.

Representative terms from entire chapter:

cmms software