Draft statement of work
Hardware Maintenance (TR-1)
Download 0.66 Mb.
|
- Navigate this page:
- 6.2.1On-site Parts Cache (TR-1)
- 6.2.2Secure FRU Components (TR-1)
- 6.3Software Support (TR-1)
- 6.4On-site Analyst Support (TR-1)
6.2Hardware Maintenance (TR-1)Offeror may supply hardware maintenance for both the Dawn and Sequoia systems for a five-year period starting with system acceptance. LLNS personnel will attempt on-site first-level hardware fault diagnosis and repair actions. Offeror will provide second-level hardware fault diagnosis and fault determination during normal business hours. That is, if LLNS personnel cannot repair failing components from the on-site parts cache, then Offeror personnel will be required to make on-site repairs. Offeror supplied hardware maintenance response time will be before the end of the next business day from incident report until Offeror personnel perform diagnosis and/or repair work. The proposed system will be installed in a limited access area vault type rooms (VTR) at LLNL and maintenance personnel must obtain DOE P clearances for repair actions at LLNL and be escorted during repair actions. USA Citizenship for maintenance personnel is highly preferred because it takes at least 30 days to obtain VTR access for foreign nationals. During the period from the start of system installation through acceptance, Offeror support for hardware will be 12 hour a day, seven days a week (0800-2000 Pacific Time Zone), with one hour response time. 6.2.1On-site Parts Cache (TR-1)A scalable parts cache (of FRUs and hot spare nodes of each type proposed) at LLNL is desired that will be sufficient to sustain necessary repair actions on all proposed hardware and keep them in fully operational status for at least one month without parts cache refresh. That is, the parts cache, based on Offeror’s MTBF estimates for each FRU and each rack, will be sufficient to perform all required repair actions for one month without the need for parts replacement and should scale up as system racks are delivered. Offeror will resupply/refresh the parts cache as it is depleted for the five year hardware maintenance period. Offeror will propose sufficient quantities of FRUs and hot-spare nodes for the parts cache. The parts cache will be enlarged, at the selected Offeror’s expense, should the on-site parts cache prove, in actual experience, to be insufficient to sustain the actually observed FRU or node failure rates. However, at a minimum, the on-site parts cache will include the following fully configured CN, ION, and LN FRUs. LLNS will store and inventory the on-site parts cache components. Parts in the parts cache are LLNS property. Failed parts become Offeror’s property when RMAed back to Offeror. Offeror may propose a Return Merchandise Authorization (RMA) reporting and tracking database that allows LLNS to report failing or failed parts and keeps track of failed FRU by serial number. Offeror will ship replacement FRU upon authorization of RMA request and not wait until LLNS returns failed FRU under the RMA. LLNS may have access to this RMA database to survey the data. RMAs may be issued to LLNS by interacting with the database. Offeror may ship replacement FRUs immediately upon RMA, while LLNS is shipping filed FRUs back to Offeror. Offeror may not wait for LLNS shipment of failed FRU to arrive at Offeror’s facility and/or waiting for supplier replacement. 6.2.2Secure FRU Components (TR-1)The selected Offeror may identify any FRU in the proposed system that persistently holds data in non-volatile memory or storage prior to system and on-site spare parts cache delivery. Selected Offeror may deliver prior to system and on-site parts cache delivery a Statement of Volatility for every and all unique FRU that contain only volatile memory or storage and thus cannot hold user data after being powered off. FRU with non-volatile memory or storage that potentially contains user data will not be returned to the Offeror. Instead, FRU with non-volatile memory or storage that could potentially contained user data will be certified by LLNS to Selected Offeror as destroyed as part of Offeror’s RMA replacement procedure under the hardware maintenance plan. 6.3Software Support (TR-1)Offeror will supply software maintenance for each Offeror supplied software component, specifically including the supplied LWK, starting with the Dawn or Sequoia system acceptance and ending five years after the Dawn or Sequoia system acceptance. Offeror provided software maintenance may include an electronic trouble reporting and tracking mechanism and periodic software updates. In addition, the Offeror will provide software fixes to reported bugs. The electronic trouble reporting and tracking mechanism may allow the LLNS to report bugs and status bug reports 24 hours a day, seven days a week. The LLNS will prioritize software defects so that Offeror can apply the software maintenance resources to the most important problems. During the period from the start of system installation through acceptance, Offeror support for supplied software will be 12 hour a day, seven days a week (0800-2000 Pacific Time Zone), with one hour response time. 6.4On-site Analyst Support (TR-1)Offeror may supply two on-site analysts to LLNS. One on-site systems programmer will be highly skilled in Linux systems programming and may support LLNS personnel in providing solutions to the current top ten issues. The systems programmer may have proficiency in C programming and familiarity with interpreted languages (e.g., Perl, Python, Expect, and Bash Shell) and have experience maintaining open source software. This includes merging with upstream releases, submission of local patches upstream, code repository maintenance, build and test process implementation. In addition the systems programmer will be highly skilled in operational activities of the proposed Dawn and Sequoia systems and may support LLNS personnel in day-to-day operations and software systems upgrades. The systems programmer will use LLNS and Offeror trouble ticket mechanisms and hardware and software problem tracking data bases to maintain an accurate systems availability, effectiveness level, calculate actual MTBAF and support response time statistics. The systems programmer may interact with the Offeror development and support organizations as an advocate for LLNS top10 issues. One on-site applications analyst will be highly skilled in applications development and porting to the Dawn and Sequoia systems. This applications analyst will provide expertise to the Tri-Laboratory ASC code development teams in the areas of software development tools, parallel applications libraries and applications performance. The proposed system will be installed in a classified area at LLNL and so analyst personnel may obtain DOE Q clearances. LLNS may request additional on-site analysts, which will be priced separately. End of Section 6 Download 0.66 Mb. Share with your friends:
|