Attachment_02.docx

Attachment 2 – Computer and Software

2.1 Computer. The following details the Government’s minimum requirements for the computer system. It remains the contractor’s responsibility to provide a computer system capable of meeting the performance requirements of all installed software, even if such a system would exceed the requirements in this document. The computer system shall have the following minimum characteristics:

2.1 .1 Operating System. The computer operating system shall be the latest of Microsoft offerings that are required to perform the tasks noted in the manuals. The contractor shall provide a copy of the physical installation media.

2.1.2 Storage. The system hard drive(s) shall have a minimum of 70% free disk space after all applications have been loaded or 1 TB, whichever is greater. Hard drives shall be configured as RAID 1 (Redundant Array of Independent Disks).

2.1.3 Displays. The system shall utilize at least one 21 inch (or larger) flat panel, Thin Film Transistor (TFT) or Active-Matrix Liquid Crystal Display (LCD). The system shall provide at least 1024 x 768 resolution and at least 24-bit color.

2.1.4 Warranty. The computer shall include at least Standard Commercial Warranty consisting of, three year, Next Business Day On-Site Service, including parts and labor. The contractor shall provide a placard detailing the computer warranty details and expiration date. The contractor shall affix the placard to computer.

2.1.5 Peripherals. The system shall be equipped with a minimum of the following peripherals:

2.1.5.1 Printer. The contractor shall supply a laser system printer suitable for use in the test stand location.

2.1.5.2 Mouse/Touch Pad. The test stand shall utilize a mouse or touch pad to perform mouse functions.

2.1.5.3 Keyboard. The keyboard shall be suitable for use in the test stand hazardous location.

2.1.5.4 Mouse/Touch Pad/Keyboard. The Mouse/Touch Pad/Keyboard may be combined unto a single unit. If the Mouse/Touch Pad and Keyboard functions are combined, the single unit shall be suitable for use in the test stand hazardous location. If the Mouse/Touch Pad and Keyboard functions are combined, this paragraph shall take the place of paragraphs 4.4.5.2 and 4.4.5.3 above.

2.2 Computer Performance characteristics. The equipment shall provide at a minimum, the capabilities, characteristics, and performance specifications described herein.

2.2.1 Measurement Accuracy. The contractor supplied system shall provide for measurement capability of testing parameters within the required accuracy as specified by the actuator manuals referenced in Section 2.1 of this equipment specification. Accuracy requirement shall be a 4:1 ratio between instrument accuracy and the required measurement.

2.3 Computer System Software Characteristics. All commercial computer software shall be licensed to FRC East, MCAS Cherry Point, NC. The computer system shall perform operator interface, data acquisition, operation, display, control functions, for the actuators noted. FRC East shall receive government purpose data rights to any software that is non-commercial and/or developed specifically for this requirement. The system shall come complete with Symantec Norton Ghost software. The Ghost software shall have the ability for total software restoration of the backup image to return the computer to the state it was in when the backup was created, in the event of a hard drive crash, failure or corruption. A “desktop” security manager application shall be installed on the computer system. The application shall be configurable for the individual user accounts to restrict access to the system setting and keep the desktop application secure. Access control is further clarified in section A2.9.22

2.4 Data Acquisition System. The data acquisition system shall comprised of National Instruments hardware to the maximum extent possible. The data acquisition system shall be comprised of Commercial-Off the Shelf hardware to the maximum extent possible. The data acquisition system shall use National Instruments Measurement and Automation Explorer (MAX) for hardware configuration only. The data acquisition system shall acquire all analog and digital input signals required by the Actuator maintenance manual referenced in Section 2.0, Paragraph 2.2.2 of this specification. The data acquisition system shall interface to test stand critical instrumentation in accordance with contractor design. Pressure Transducers, Resistance Temperature Detectors (RTDs), Thermocouples, Stepper Drive Voltage, Impact Flow Meters shall be included as appropriate. The data acquisition system shall have sufficient resolution, accuracy, stability, and scan rates to accurately measure and calibrate test stand and Actuator parameters. The data acquisition system shall provide sufficient memory and data storage capabilities to operate without systems degradation when operated as detailed in this specification. The data acquisition system shall have a minimum 25 % extra channel capacity.

2.5 Control System. The control system shall be either implemented in the specified National Instruments hardware and software solution or by a Programmable Logic Controller (PLC/PAC). The control system design shall provide for a controlled shutdown in the event of computer failure. The control system shall be comprised of Commercial-Off the Shelf hardware to the maximum extent possible. If implemented in the specified National Instruments hardware and software, the control system shall NOT use National Instruments Measurement and Automation Explorer (MAX) for calibration. The control system shall have sufficient analog and digital output channels to meet requirements all parameters required by the Actuator manual referenced in Section 2.0, Paragraph 2.2.2 of this specification. The control system shall have sufficient resolution, accuracy, stability, and control rates to accurately control the test stand and Actuator parameters.

2.5.1 Programmable Logic Controller (PLC). Any Programmable Logic Controllers (PLC’s) shall be of Allen-Bradley manufacture. The contractor shall use the AB Standard for code development, Publication Number IA-RM001C-EN-P Integrated Architecture Foundations of Modular Programming.

2.5.1.1 Backup. The contractor shall provide a backup to the PLC software, Any host computer software, and all Human Machine Interfaces (HMI). The backups shall be provided on CD-ROM with written back-up/recovery instructions.

2.6 Software.

2.6.1 Programming Environment. Acceptable programming languates shall be defined in terms of the contractor’s implemented solution. National Instruments Labview and Rockwell automations software suite are acceptable solutions. A copy of all contractor developed software and all development software applications shall be delivered to the government.

2.6.2 Ladder Logic. If a PLC is employed in the contractor’s solution, the contractor shall provide a commented version of the ladder logic as well as the development versions used for the HMI to be used for future editing, modifying, or inspection by the government.

2.6.3 Addressing. Digital and analog input/output addresses are not to be used in the program machine control files, subroutines or modules. Instead, all hardware IO points shall be written to memory markers or registers in dedicated files. Digital inputs shall be written to/from markers in blocks. Digital and analog inputs shall be processed in a file before the machine control code and digital and analog outputs shall be processed after the machine control code.

2.6.4 Scaling. Scaling of analog inputs and outputs shall be performed in the same file where the hardware point is being read from or written to. Scaled values within the program shall be 0 to 10,000 full-range.

2.6.5 Alarm Monitoring. Where a hardware input is being monitored for an alarm, this marker shall not be used in the program for machine control. Instead the inverse of the alarm shall be used. For example: A water-cooled power supply is used on the machine, if water flow is not detected the power supply shall not be shut off before generating an alarm, therefore a “NO WATER FLOW FAILURE” Alarm condition shall be used to switch on the power supply instead of the “WATER FLOW = PRESENT” input marker.

2.6.6 HMI. In a system that uses PLC and HMI during machine operation, the PLC shall always be in control of all processes. If the PLC loses communication with the HMI, the machine shall fall into a safe situation, such as standby and the process shall wait until contact is re-established and the process can resume.

2.6.7 Naming. All program elements shall be labeled in a self-documenting fashion that is descriptive of the function.

2.6.8 HMIs. All touch screen HMI interfaces shall be of Allen-Bradley manufacture.

2.6.9 Copies of Software. A licensed copy of all software used for this contract shall be provided as a deliverable. This software shall be delivered prior to final acceptance.

2.7 Software Quality Assurance (SQA). The contractor shall have a pro-active Software Quality Assurance program in conformance with IEEE/EIA 12207 and the Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI) Level II and the applicable Key Process Areas (KPA’s) from Level III. Selected areas (KPAs) in Level III include Technical Solution, Product Integration, Verification, and Validation. The contractor shall provide artifacts from the Specific Practices of the KPAs to government monthly to ensure Software Quality Assurance IAW the SEI-CMMI levels. The SQA process shall extend to any system or device that integrates with system software or is a software configurable item. The scope of the SQA process will be throughout the life of the project until the end of the warranty period.

2.8 Software programming design

2.8.1 Programming language. The programming language shall be the latest stable debugged version of National Instruments LabVIEW compatible with the operating system and appropriate hardware drivers.

2.8.2 LabVIEW. Conform to LabVIEW coding style and documentation standards. The contractor’s solution shall be structured so that NO scrolling is required for the developed code. Sub-VI’s shall be used to reduce the block diagram layout. The contractor shall refer to the Development Guidelines section of the LabVIEW “help” for more information about the LabVIEW style checklist and creating in-program documentation. The following specific points are adapted from the LabView style guide and are specific style requirements that are modified from the style check list.

2.8.2.1 The contractor shall give controls meaningful labels and captions. The label/name of a control or indicator shall describe its function. I/O devices shall be labeled and indicate the Analog or Digital channel they represent. If the control is visible to the user, use captions to display a long description and add a short label to prevent using valuable space on the block diagram where applicable. For example, when you label a ring control or slide control that has options for volts, ohms, or amperes, select an intuitive name for the control. For example, a caption such as "Select units for display" is a better choice than "V/O/A". Use Property Nodes to change captions programmatically where applicable.

2.8.2.2 The contractor shall use consistent capitalization, and include default values and unit information in label names. For example, if a control sets the high limit temperature and has a default value of 75 °F, name the control high limit temperature (75 degF). If you will use the VI with the control on multiple platforms, avoid using special characters in control names. For example, use degF instead of °F, because the ° symbol might not display correctly on other platforms. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.3 For Boolean controls the contractor shall use the name to give an indication of which state (TRUE or FALSE) corresponds to the function (for example, ON) and indicate the default state in parenthesis. For checkboxes and radio buttons, the user can click the Boolean text of the control and the value of the Boolean control changes. Free labels next to a Boolean control can help clarify the meaning of each position on a switch. For example, use free labels like Cancel, Reset, and Initialize that describe the action taken.

2.8.2.4 The Context Help window is required to display labels as part of the connector pane. If the default value is essential information, place the value in parentheses next to the name in the label. Include the units of the value if applicable.

2.8.2.5 The contractor shall set controls with reasonable default values. A VI should not fail when run with default values. Do not set default values of indicators like graphs, arrays, and strings without a good reason because that wastes disk space when saving the VI. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.6 The contractor shall ensure the background of control and indicator labels are transparent. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.7 The contractor shall use consistent placement of control labels.

2.8.2.8 The contractor shall use standard, consistent fonts—application, system, and dialog—throughout all front panels. Limit the VI to the three standard fonts (application, system, and dialog) unless you have a specific reason to use a different font. For example, monospace fonts, which are fonts that are proportionally spaced, are useful for string controls and indicators where the number of characters is critical. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.9 The contractor shall use path controls instead of string controls to specify the location of files or directories. When specifying the location of a file or directory, use a path control or indicator. Path controls and indicators work similarly to strings, but LabVIEW formats paths using the standard syntax for the platform you are using. Set the browse options appropriately for the Browse button of path controls. For example, if the user needs to select a directory, select the Folders only and Existing only options on the Browse Options page of the Path Properties dialog box. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.10 The contractor shall configure numeric inputs with data ranges. Expect the user to supply invalid values to every control. Right-click the control and select Data Entry to set the control item to coerce invalid values into a desired range: Minimum, Maximum, and Increment. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.11 The contractor shall write descriptions and create tip strips for controls and indicators, including array, cluster, and refnum elements. To describe the purpose of the object and to give users instructions for using the object, create descriptions and tip strips for the object.

2.8.2.12 The contractor shall arrange controls logically. Consider the arrangement of controls on front panels. Keep front panels simple to avoid confusing the user. For top-level VIs that users see, place the most important controls in the most prominent positions. For subVI front panels, place the controls and indicators of the sub VI so that they correspond to the connector pane pattern.

2.8.2.13 The contractor shall group and arrange controls attractively. Use the Align Objects and the Distribute Objects pull-down menus to create a uniform layout. Use decorations, such as a Raised Box or Horizontal Smooth Box, to visually group objects with related functions. Use clusters to group related data. Do not use clusters for aesthetic purposes only. Do not overlap controls with other controls, with their label, digital display, or other objects unless you want to achieve a special effect. Overlapped controls slow down screen updates and can make the control or indicator flicker.

2.8.2.14 The contractor shall use color logically, sparingly, and consistently, if at all. Color can distract the user from important information. For instance, a yellow, green, or bright orange background makes it difficult to see a red danger light. Use a minimal number of colors, emphasizing black, white, and gray. The following are some simple guidelines for using color:

2.8.2.15 The contractor shall never use color as the sole indicator of device state. Do not use black and white lines in multiplot graphs/charts. Use lines for plot styles in addition to color.

2.8.2.16 The contractor shall consider coloring the pane backgrounds on the front panel background and objects of user interface VIs with the system colors, or symbolic colors, in the color picker. System colors adapt the appearance of the front panel to the system colors of any computer that runs the VI.

2.8.2.17 The contractor shall use light gray, white, or pastel colors for backgrounds. The first row of colors in the color picker contains less harsh colors suitable for front panel backgrounds and normal controls. The second row of colors in the color picker contains brighter colors you can use to highlight important controls. Select bright, highlighting colors only when the item is important, such as an error notification.

2.8.2.18 The contractor shall provide a stop button if necessary. Do not use the Abort button to stop a VI. Hide the Abort button. The Abort Execution button stops the VI immediately, before the VI finishes the current iteration. Aborting a VI that uses external resources, such as external hardware, might leave the resources in an unknown state by not resetting or releasing them properly. Deviations to this guidance shall be approved by the Government in writing before the start of acceptance testing.

2.8.2.19 The contractor shall use ring controls and enumerated type controls where appropriate. If you are using a Boolean control for two options, consider using an enumerated type control instead to allow for future expansion of options. When using enumerated type controls, always make a type definition of the control. Creating type definitions prevents you from needing to rewrite the code each time you add or remove an item from an enumerated type control. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.20 The contractor shall use type definitions for common controls, especially for enumerated type controls and data structures. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.21 The contractor shall label custom controls with the same name as the file. For example, Alarm Boolean.ctl has the default name Alarm Boolean. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.22 The contractor shall make sure all the controls on the front panel are of the same style. For example, do not use both classic and modern controls on the same front panel. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.23 The contractor shall use Property Nodes to give the user more feedback on the front panel and to make the VI easier to use. The following are examples of how Property Nodes can enhance ease of use in an application or VI:

2.8.2.24 The contractor shall set the text focus to the main, most commonly used control.

2.8.2.25 The contractor shall disable or hide controls that are not currently relevant or valid.

2.8.2.26 The contractor shall guide the user through steps by highlighting controls.

2.8.2.27 The contractor shall change colors to bring attention to error conditions.

2.8.2.28 The contractor shall modify front panel objects in subVIs using control references. Use the control refnum controls to pass front panel object references to other VIs. After you pass a control reference to a subVI, use Property Nodes and Invoke Nodes to read and write properties and invoke methods of the referenced front panel object. Control references reduce the clutter on the block diagram.

2.8.2.29 The contractor shall use imported graphics to enhance the front panel. You can import graphics and text objects to use as front panel backgrounds, items in picture rings, and parts of custom controls and indicators. Check how the imported graphics look when you load the VI on another platform.

2.8.2.30 The contractor shall not place indicators and controls on top of a graphic object so that LabVIEW does not have to redraw the object each time the indicator updates. If you must use a large background picture with controls on top of it, divide the picture into several smaller objects and import them separately because large graphics usually take longer to draw than small ones. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.31 The contractor shall set up key navigation and keyboard shortcuts for controls and indicators on the front panel. Set the tabbing order for the objects to read left to right and top to bottom. Set the <Enter> key as the keyboard shortcut for the front panel default control, which is usually the OK button. Exception, if you have a multiline string control on the front panel, the use the <Enter> key as a shortcut may not be advisable. If the front panel has a Cancel button, set the <Esc> key to be the keyboard shortcut. You also can use function keys as navigation buttons to move from screen to screen. If you do this, be sure to use the shortcuts consistently. Select Edit»Set Tabbing Order to arrange controls in a logical sequence when the user needs to tab between the controls. For controls that are offscreen, use the Key Navigation tab of the Properties dialog box to skip over the controls when tabbing or to hide the controls. Also consider using the key focus property to set the focus programmatically to a specific control when the front panel opens. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.32 The contractor shall create dialog boxes to help users input data. Use system controls in the dialog box you create to prompt users to configure and set the options for the dialog box. Consider using tab controls, which group front panel controls and indicators in a smaller area, to reduce clutter in a dialog box. Do not overuse dialog box is overuse announce messages to the user. Use a status text window to display less serious warnings.

2.8.2.33 The contractor shall avoid creating extremely large block diagrams. Limit the scrolling necessary to see the entire block diagram to one direction. The size of the block diagram window can affect how readable LabVIEW code is to others. Make the block diagram window no larger than the screen size. If the code is too large to fit on one screen, make sure the user has to scroll only in one direction to view the rest of the code. If the block diagram requires scrolling, consider using subVIs. Deviations from this guidance shall be approved by the Government prior to the start of acceptance testing.

2.8.2.34 The contractor shall label Call Library Function Nodes, Code Interface Nodes, and algorithms. Use the following for documenting the block diagram.

2.8.2.35 The contractor shall use labels on Call Library Function Nodes to specify what function the node is calling and the path to the library the node calls.

2.8.2.36 The contractor shall use free labels to document algorithms that you use on the block diagrams. If you use an algorithm from a book or other reference, provide the reference information.

2.8.2.37 The contractor shall not show labels on function and subVI calls because they tend to be large and unwieldy. A developer looking at the block diagram can find the name of a function or subVI by using the Context Help window.

2.8.2.38 The contractor shall show name of source code or include source code for any CINs.

2.8.2.39 The contractor shall use comments on the block diagram to explain what the code is doing. Use free labels to describe how the block diagram functions.

2.8.2.40 The contractor shall avoid creating excessive wire patterns and colors if you change the wire appearance of a LabVIEW class wire. Change the wire appearance of LabVIEW class wires only when it is necessary to differentiate between other class wires in the block diagram window.Use the standard application font in free labels on all block diagrams.

2.8.2.41 The contractor shall use Size to Text for all text for portability and add carriage returns if necessary. The actual font used for the three standard fonts (application, system, and dialog) varies depending on the platform. For example, when working on Windows, preferences and video driver settings affect the size of the fonts. Text might appear larger or smaller on different systems, depending on these factors. To compensate for this, allow extra space for larger fonts and enable the Size to Text option on the shortcut menu.

2.8.2.42 The contractor shall make sure data flows from left to right and wires enter from the left and exit to the right. Use small free labels with white backgrounds to label long wires to identify their use. Labeling wires is useful for wires coming from shift registers and for long wires that span the entire block diagram. Add as few bends in the wires as possible and keep the wires short. Avoid creating wires with long complicated paths because long wires are confusing to follow. Deviations from this guidance shall be approved by the Government prior to the start of acceptance testing.

2.8.2.43 The contractor shall align and distribute functions, terminals, and constants. Use the Align Objects and Distribute Objects pull-down menus on the toolbar to arrange objects symmetrically on the block diagram.

2.8.2.44 The contractor shall not place block diagram objects, such as subVIs or structures, on top of wires, and do not wire behind objects. Draw wires so that you can clearly see if a wire correctly connects to a terminal. Delete any extraneous wires. Do not wire through structures if the data in the wire is not used in the structure. Deviations from this guidance shall be approved by the Government prior to the start of acceptance testing.

2.8.2.45 The contractor shall use path constants instead of string constants to specify the location of files or directories. Use a path constant and the path data type to supply a constant path value to the block diagram. The path constant and data type use the platform-specific notation for paths, unlike the string constant and data type. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.46 The contractor shall ensure the program can deal with error conditions and invalid values.

2.8.2.47 The contractor shall use sequence structures sparingly because they hide code. If flow-through parameters are not available and you must use a sequence structure in the VI, consider using a Flat Sequence structure. Rely on data flow rather than sequence structures to control the order of execution. With sequence structures, you break the left-to-right data flow paradigm whenever you use a sequence local variable. To help control data flow, you can use error clusters instead.

2.8.2.48 The contractor shall ensure the subVI icon, rather than the connector pane, is visible on the block diagram. The subVI icon is more helpful than the connector pane on the block diagram. Right-click the subVI and select Visible Items and ensure there is no checkmark next to the Terminals option. The contractor shall document the rational for deviations from this guidance in the source code comments.

2.8.2.49 The contractor shall use a type definition when you use the same unique control in more than one location or when you have a very large data structure passing between several subVIs.

2.8.2.50 The contractor shall open references to a LabVIEW object, such as an application, control, or VI, close the references by using the Close Reference function. Deviations from this guidance shall be approved by the Government prior to the start of acceptance testing. Avoid using local variables when you can use a wire to transfer data. Use global and local variables as sparingly as possible. Rational for the use of each global variable shall be included in the source code comments.

2.8.2.51 The contractor shall organize VIs in a hierarchical directory with easily accessible top-level VIs and subVIs in subdirectories. Organize the VIs in the file system to reflect the hierarchical nature of the software. Make top-level VIs directly accessible. Place subVIs in subdirectories and group them to reflect any modular components you have designed, such as instrument drivers, configuration utilities, and file I/O drivers. Limit the number and levels of directories you use in a project.

2.8.2.52 The contractor shall use the VIs as subVIs, create a .mnu file. Hide dependent subVIs. Arrange the palettes and name the menus logically.

2.8.2.53 The contractor shall avoid using absolute paths in VIs. Using absolute paths might cause problems when you build an application or run the VI on a different computer. If you must use an absolute path, ensure that you include code to test that the path exists and to create the path if it does not exist.

2.8.2.54 The contractor shall give VIs meaningful names without special characters, such as backslash (\), slash (/), colon (:), and tilde (~). When naming VIs, LLBs, and directories, avoid using characters not all file systems accept, such as backslash (\), slash (/), colon (:), and tilde (~). Avoid creating files with the same name anywhere within the hierarchy. Only one VI of a given name can be in memory at a time. If you have a VI with a specific name in memory and you attempt to load another VI that references a subVI of the same name, the VI links to the VI in memory.

2.8.2.55 The contractor shall use standard extensions (.vi, .ctl) so the operating system can distinguish files.

2.8.2.56 The contractor shall distinguish example VIs, top-level VIs, subVIs, controls, and global variables by saving them in subdirectories or separate libraries in the same directory or by giving them descriptive names, such as X Main.vi, X Example.vi, X Global.vi, and X TypeDef.ctl. Create a directory for all the VIs for one application and give it a meaningful name. Save the main VIs in this directory and the subVIs in a subdirectory. If the subVIs have subVIs, continue the directory hierarchy downward. When you create the directory, organize the VIs and subVIs modularly according to the functionality of the subVIs.

2.8.2.57 The contractor shall write a VI description, proofread it, and confirm that it displays correctly in the Context Help window. Describe how to use the VI and any required parameter settings in the VI Description on the Documentation page of the VI Properties dialog box.

2.8.2.58 The contractor shall create a meaningful icon for every VI. The icon represents the VI on a palette and a block diagram. Use the following suggestions when creating icons. Create a unified icon style for related VIs to help users visually understand what subVIs are associated with the top-level VI.

2.8.2.59 The contractor shall use a consistent connector pane layout across related VIs. Wire inputs on the left and outputs on the right to follow the standard left-to-right data flow. If creating a group of subVIs that are used together often, give the subVIs a consistent connector pane with common inputs in the same location to help you remember where to locate each input. If creating a subVI that produces an output another subVI uses as the input, such as references, task IDs, and error clusters, align the input and output connections to simplify the wiring patterns. When assigning terminals as inputs and outputs, make sure to split the terminals of the connector pane consistently. If you need to use the middle four terminals of the 4 × 2 × 2 × 4, divide them either horizontally or vertically. For example, assign the inputs to the top two terminals and the outputs to the bottom two terminals or assign the inputs to the left two terminals and the outputs to the right two terminals.

2.8.2.60 The contractor shall not use connector panes with more than 16 terminals. Rational for the use of each global variable shall be included in the source code comments.

2.8.2.61 The contractor shall use Required, Recommended, and Optional settings on the connector pane. Use the Required setting for inputs that users must wire for the subVI to run properly. Use the Optional setting for inputs that have default values that are appropriate for the subVI most of the time.

2.8.2.62 The contractor shall make good use of reusable, testable subVIs.

2.8.2.63 The contractor shall use error in and error out clusters in all subVIs. Include error in and error out clusters in all subVIs, even if the subVI does not process errors. error in and error out clusters are helpful for controlling execution flow. If a subVI has an incoming error, you can use a Case structure to send the error through the VI without executing any of the subVI code.

2.8.2.64 The contractor shall design the VI for maximum performance. Although optimization can be an involved topic, you can take the following basic actions to optimize an application:

2.8.2.65 The contractor shall force less important parallel tasks to wait using the Wait (ms) function so crucial tasks have more processor time.

2.8.2.66 The contractor shall Event structures where possible, especially for user interface events.

2.8.2.67 The contractor shall avoid building arrays using the Build Array function within a loop.

2.8.2.68 The contractor shall avoid using autoscaling on graphs and charts if you do not need it.

2.8.2.69 The contractor shall choose the proper array data type for the data to be handled to control the memory usage of the application. For example, if you have an extended-precision, floating-point array of 100,000 values, but the actual values stored in the array are single-precision, floating-point values, there is an inefficient use of memory. Using an array of single-precision, floating-point values to match the data type stored in the array reduces the memory usage.

2.8.2.70 The contractor shall display only the necessary information on the front panel and send data to indicators only if the data is different from what the indicator already displays.

2.8.2.71 Revision Tracking. The contractor shall turn on and use LabVIEW’s revision history mechanisms (typically found in VI properties). Each Virtual Instrument (VI) shall be configured to ask the programmer for input each time the file is saved when it is delivered to the Government. The latest revision, with revision number, shall be provided to the government at PAT. This revision shall include all LabView block diagram and elements.

2.9 Software Design. Developed Software.

2.9.2 Development software. The contractor shall provide copies of all development software required to develop and compile any aspect of the delivered system to the Government. The software shall be licensed to the FRC East.

2.9.3 Compilation. The final accepted software version shall be installed as a compiled executable. The contractor shall provide a current version of the compiled source code.

2.9.4 Productivity Software. Provide the Microsoft’s most recent version of its Microsoft Office (including Word, Excel, PowerPoint).

2.9.5 Screen Refresh Rate. The software shall have a minimum of 4Hz screen refresh rate for textual data. The software shall have a display refresh rate of at least 10 HZ for graphic data.

2.9.6 Software Refresh Rate. The software shall have a refresh rate of 20 refreshes per second, minimum, all acquisition channels, with updated data from the acquisition system and PLC.

2.9.7 TPS Philosophy. The application shall be created with the philosophy of creating a separate sub program (examples: VI, subroutine, recipe) that is easy to modify and create to handle the actual test procedure. Additional tests or TPS shall be created, removed, or modified at relative ease.

2.9.8 Alarms. Provide alarm enunciation. All current alarms shall be visible at any given time. The alarm shall be listed by mnemonic and current value, updating value. When the alarm returns to a normal state, it shall be removed from the enunciation screen. Enunciation shall be listed as First In, First Out (FIFO) order. The contractor shall be responsible for defining alarm conditions in the software and taking automated action, where applicable, to ensure the safety of personnel, equipment, and the unit under test.

2.9.8.1 Multiple Alarm Definitions. Multiple alarm definitions shall be allowed for each channel.

2.9.8.2 Latency. A definable latency time and/or dead band shall be provided for each alarm to prevent transient data from triggering a false alarm.

2.9.8.3 Enable/Disable. The user and the TPS shall have the ability to dynamically enable and disable alarm actions. Alarm values shall be capable of being dynamically defined, by the operator and the TPS. Alarms shall not be enabled until they are relevant.

2.9.8.4 Types. Alarm calculations shall be, but not limited to, a constant, a calculated channel (dependant on one or more parameters, executed mathematically/logically), or a table lookup dependent on dynamic test conditions.

2.9.8.5 Logging. Alarms shall be logged to an event log. They system shall log any action taken because of an alarm and what event triggered the alarm.

2.9.8.6 Triggering. Alarms shall be capable of triggering an automated procedure. The contractor shall provide procedures to safely deal with alarms.

2.9.8.7 Hierarchy. A hierarchical alarm method shall be employed to prioritize alarm events and prevent higher priority alarms that trigger a procedure from being interrupted by a lower priority alarm.

2.9.8.8 Warnings. The warnings display shall display all events that exceed a set limit value. The contractor shall configure the limits. Limits shall be easily configurable and not require a re-compilation of the system.

2.9.8.9 Damage Prevention. Alarms shall be configured to trigger with associated action before damage is done to the engine, the test facility, or presents safety hazard(s) to personnel (for example: sufficiently triggered before over speed and over temps limits to allow the engine to spool to a safe state before any hard limit or time limit is exceeded).

2.9.8.10 Fixed. The warnings display shall always be displayed during unit testing and shall be fixed and unmovable.

2.9.8.11 Information Displayed. The warnings display shall, as a minimum, display the parameter name, limit value exceeded, current measured value.

2.9.9 Logs. The software shall create a text log of major events that occur during testing, including errors. The log entries shall be time stamped for troubleshooting. Log all operator interactions, prompts, user responses.

2.9.10 Displays. The contractor shall optimize the layout of the display screens to present the operator an efficient annunciation system. Display screens shall be provided in accordance with MIL-STD-1472 – Human Engineering. For the purpose of this spec and how it interacts with the MIL-STD-1472 - Human Engineering, the terms CRT and LCD monitor shall be interchangeable.

2.9.10.1 Caution. Display indicators/gauges shall have a yellow background for caution limit excursions.

2.9.10.2 Warning. Display indicators/gauges shall have a red background and a blinking foreground for warning limit excursions.

2.9.10.3 Normal. Display indicators shall have the standard background color for parameters that are within all limits and considered normal. The text shall be a high contrast color.

2.9.11 Charts in Test Pub. Each chart in the test documents shall have a duplicate chart created in software. The screen shall display plotted data in real time.

2.9.12 Test System/Stand Overview. The contractor shall provide a display routine that displays a test stand overview depiction.

2.9.13 Test Sequencing. The software shall provide the capability of running the tests out of the order in the test publication.

2.9.14 Reports. The software shall provide the functionality to print reports. The reports are detailed in section A2.10.6.

2.9.15 Print Preview. Provide a print preview option to for operator to view reports in a What You See is What You Get (WYSIWYG) format before printing.

2.9.16 Configurability. The software shall provide administrative functionality to customize or create new reports.

2.9.17 Database. The system shall be able to create reports for previously ran, database stored engine runs.

2.9.18 Backup. The system shall provide utilities to backup restore archived records.

2.9.19 Charts/Graphs. The reports shall contain all required graphs/charts and be generated automatically by the software.

2.9.20 Diagnostics. The software shall include maintenance functions for all devices interfaced in the system. A real time display shall be integrated into the software that shows the status of each communication link. Diagnostics shall be included for each hardware device that can be run from the software to ensure the proper operation of each device. The Maintenance Function shall also allow for the backup and restore of files to floppy disk and CD/DVD disks.

2.9.21 Access Control. The system shall implement a password-based scheme of controlling system access levels based on user groups. Protection shall be implemented at the Operating System level. The system shall have the following user groups with password protection controls:

2.9.21.1 Administrator. The administrator shall be given all available access privileges.

2.9.21.2 Operator. The operator shall be given access to all test programs and tasks relating to testing. The operator shall not have operating system access.

2.9.21.3 Calibration Technician. The calibration technician shall be given access to calibration and related tasks only.

2.9.21.4 Maintenance Technician. The maintenance technician shall be given access to all tasks relating to hardware or software maintenance.

2.9.22 Calibration. The software shall have a calibration utility to guide the technician though the calibration process.

2.9.22.1 Function. The calibration utility shall scale/calibrate data channels to compensate for sensor non-linearity and set units to engineering values. The calibration utility shall allow technicians to verify cardinal points without having to scale the parameter.

2.9.22.2 Method. The test system shall use software calibrations. The calibration utility shall have a selectable method of calibration. The methods shall be polynomial fit (up to 2nd order), look-up table (with interpolation), and linear fit.

2.9.22.3 Live Data Reading. The calibration utility shall display a live data reading with a selectable time and sample based FIFO averaging. When selected, the filtered value shall be the value used for calibration calculations.

2.9.22.4 Number of Data Points. The calibration utility shall allow a selectable number of calibration data points. The software shall allow for at least 20 calibration points.

2.9.22.5 Interface. The calibration utility shall apply the newly generated calibration constants and display the mean calibration error, max calibration error, and provide a graphical representation of the calibration curve fit.

2.9.22.6 Storage Prompt. The calibration utility shall provide a user prompt and verification to store calibration data to disk.

2.9.22.7 History. The calibration utility shall store, as a minimum, the current calibration and previous five calibration cycles.

2.9.22.8 Report. The calibration utility shall provide a calibration report of single, multiple, or entire channel calibration information. A calibration report shall include latest calibration information, historical calibration information, and determine sensor offset and drift.

2.9.22.9 Backup. The calibration utility shall provide a means to backup and restore calibration information.

2.9.22.10 Calibration Laptop. The system shall include capability to use a calibration laptop. The system shall be compatible to use a program such as “PC Anywhere”,AT&T’s VNC, or equal program to remotely control the host computer for all calibration tasks. The contractor shall provide this software to be installed by the Government on a Government laptop. The terminal shall have an Ethernet connection to the host computer. The Contractor shall provide adequate Ethernet cable to reach both sides of test bed and a properly rated Ethernet outlet inside the test cell.

2.9.22.11 Significant Digits. The number of digits displayed before or after the decimal shall be selectable by the system administrator. By default, all values displayed to the operator shall adhere to the rules of significant digits/figures (with the exception of calibration screens). The number of significant figures is the number of digits needed to express the number to within the uncertainty of measurement. For example, if a quantity had been measured to be 1.234 ±0.002, four figures would be significant. No more figures should be given than are allowed by the uncertainty. For example, a quantity written as 1.234±0.1 is incorrect; it should really be written as 1.2±0.1. Calibration users shall see the full DAQ resolution.

2.9.22.12 Processor sensitivity during calculations. If the capability for analysis is provided in the internal processor, calculation for this purpose may be conducted with as many significant digits that the internal processor will allow.

2.9.23 Operating System Functionality. The operating system shall be capable of disabling the task bar and “start menu” for all users, except users in the Administrator and Maintenance Technician groups. The system shall not permit users that are not in the Administrator or Maintenance Technician groups run programs other than the Test Application detailed in this specification.

2.9.24. System Backup. Hard disk mirroring shall be employed as the primary means of backing up the system. The contractor shall provide means to mirror the system. Mirrored disks shall be directly interchangeable with the original disks without modification (hardware or software). In addition to the drives in RAID 1 (Redundant Array of Independent Disks) configuration, the contractor shall provide an additional mirrored drive to serve as a backup. Provide step by step instructions in the Software Administrator’s Manual.

2.9.25 Non-PC Backups. Emphasis: The following paragraph applies for all programmable electronic systems or electrical systems requiring configuration (DIP switches, menu settings, etc).

2.9.25.1 Provide an electronic backup. The electronic backup shall include step-by-step instructions to restore the system and instructions to create additional electronic backups.

2.9.25.2 Instructions. Written, step-by-step, instructions to manually re-configure the device to a state compatible with the system from the state shipped from the OEM. This method shall only be employed if the system restoration is estimated to take less than two hours. If the system restoration is expected to take longer, an automated method is required. This includes hardware devices such as vibration controllers, power supplies, PID (Proportional, Integral, and Differential) controllers, and other various hardware that is shipped from the OEM, requiring additional setup before installation.

2.9.26 Allen Bradley. The programming environments shall be the development versions of Rockwell’s RsLogix and RsView. The developed software shall comply with Allen Bradley Catalog Number IA-RM001B-EN-P - Integrated Architecture TM: Foundations of Modular Programming.

2.9.27 Ladder Logic. Provide a commented version of the ladder logic as well as the development versions of used for the HMI to be used for future editing, modifying, or inspection by the Government

2.9.28 Addressing. Digital and Analog Input/Output addresses are not to be used in the program machine control files, subroutines or modules. Instead, all hardware IO points shall be written to memory markers or registers in dedicated files. Digital Inputs shall be written to/from markers in blocks. Digital and Analog inputs should be processed in a file before the machine control code and Digital and Analog outputs should be processed after the machine control code.

2.9.29 Scaling. Scaling and unscaling of Analog inputs and outputs shall be performed in the same file where the hardware point is being read from or written to. Scaled values within the program should be 0 to 10,000 full-range.

2.9.30 Alarm Monitoring. Where a hardware input is being monitored for an alarm, this marker should not be used in the program for machine control. Instead the inverse of the alarm should be used. For example: A water-cooled power supply is used on the machine, if water flow is not detected the power supply should not be shut off before generating an alarm, therefore a “NO WATER FLOW FAILURE” Alarm condition should be used to switch on the power supply instead of the “WATER FLOW = PRESENT” input marker.

2.9.31 HMI. In a system that uses PLC and HMI during machine operation, the PLC will always be in control of all processes. If the PLC loses communication with the HMI the machine will fall into a safe situation, such as standby and the process will wait until contact is re-established and the process can resume.

2.9.32 Naming. All program elements shall be descriptively labeled.

2.10 Test Executive Software. The contractor shall use the current test specifications for each Actuator as specified in Section 2.1 of this equipment…