SOLICITATION NOTICE
13 -- Prime System Intergrator for the Advanced EOD Robotic System (AEODRS) Increment 1
- Notice Date
- 5/1/2014
- Notice Type
- Cancellation
- NAICS
- 334511
— Search, Detection, Navigation, Guidance, Aeronautical, and Nautical System and Instrument Manufacturing
- Contracting Office
- N00174 Naval Surface Warfare Center, Maryland 4072 North Jackson Road Suite 132 Indian Head, MD
- ZIP Code
- 00000
- Solicitation Number
- N0017413R0043
- Response Due
- 1/7/2014 3:00:00 PM
- Archive Date
- 5/20/2014
- Point of Contact
- Omar Roque, Phone: 3017446607, Jessica D. Scalfaro, Phone: 3017446614
- E-Mail Address
-
omar.roque@navy.mil, jessica.scalfaro@navy.mil
(omar.roque@navy.mil, jessica.scalfaro@navy.mil)
- Small Business Set-Aside
- N/A
- Description
- SUMMARY OF CHANGES The purpose of this amendment is to answer outstanding question and cancel the subject solicitation prior to the receipt of proposals. Accordingly, subject solicitation is hereby updated as follows: 1. The following questions submitted prior to the suspension of the RFP are hereby answered below: Question 1: There is an inconsistency between the ICD for PWR and the MPS-EEF power requirement. According to ICD-PWR, the peak power to CM-MAN/CM-EEF/CM-VIS is 5A for 3.5s and 2.5A steady state. The MPS-EEF document specifies power of 1A steady state and 20A peak for 3.5s. The ability to provide 20A to the End Effector for 3.5s will drive wiring and electronics design in CM-MAN. Please clarify the peak power requirement for CM-EEF. Answer 1: Answered under previous amendment. Question 2: System Specification 6.2.3 states: The Dismounted Operations System shall demonstrate the ability to address objects within reach (minimum through full extension) within an angular extent of plus or minus ninety (±90) degrees azimuth and plus or minus ninety (±90) degrees of elevation. Due to the CM-MAN mounting requirement, when the manipulator is near +/- 90 degrees azimuth the vehicle is under the manipulator such that a negative elevation angle at full extension is not possible without collision. Can we interpret this specification to be manipulator range of motion without regard to the vehicle interference that is a result of the required mounting position? Answer 2: Yes, that is the intent. Question 3: The RFP refers to the AEODRS system and the AEODRS FoS interchangeably. Is there a relationship, contractual or otherwise, between Increment 1 and any other AEODRS Increments? Answer 3: There is no contractual relationship between Increment 1 and Increment 2 or Increment 3. The increments are related in that they are based on a common and open architecture. Question 4: System Specification 12.5 states: System shall be operable after decontamination with a five percent bleach solution. Vehicle shall be operable after cleaning with common household cleaner and fresh water. We believe this requirement is reversed and should read the Vehicle shall be operable after decontamination with a five percent bleach solution. The system shall be operable after cleaning with common household cleaner and fresh water. Is this correct? Answer 4: These requirements should be separated as follows: (T) System shall be operable after decontamination with a five percent bleach solution. (T) Vehicle shall be operable after cleaning with common household cleaner and fresh water. Question 5: The Government in Answer #6 states that the tech data package E2IF-0183 will not be provided until after contract award. This is quite concerning as there is not enough information in the ICDs and performance specifications to accurately cost the EEIF. There is no information on the number of parts, the complexity, required machining tolerances, or materials. Machining tolerances, especially, can cause large swings in the cost of parts. It is our understanding that one potential CM-EEF and CM-MAN supplier has access to the Government-owned technical data for the EEIF but no other suppliers do. This raises a concern that the Government will not receive the benefit of best value and full competition for the CM-MAN and CM-EFF. Will the Government please provide this requested information to all potential offerors? Answer 5: The BOM for EEIF is available for release. The entire TDP will not be made available until after award. Question 6: System Specification 7.10 states: Shall have the ability to accept automatic, programmable user presets to include camera position, manipulator positions, end effector positions, driving positions, etc. that are stored in profiles on the OCU. This is an OCU software requirement that is not in the OCU MPS. The earlier Q&A indicated the Government furnished MOCU software will be V1.3.1 complaint. Can we assume that MOCU will meet this requirement? If not, please clarify. Answer 6: Yes, MOCU meets this requirement. Question 7: System Specification 8.2.1 states: Provide fundamental control of both the Tactical Operations and Base/Infrastructure Platforms through a fixed subset of functions featured on the AEODRS Common OCU. The AEODRS Common OCU is not defined. We assume that if the Handheld OCU is complaint to the HOCU-MPS and HOCU-ICD, then we are compliant with this requirement. Is this correct? If not, please clarify. Answer 7: Yes. Question 8: System Specification 8.3.1 states: Handheld controller shall also provide the ability to select navigation waypoints through: - Designation on a 2-D geographic map - Designation from the Primary (color) video feed - Text Entry of Latitude and Longitude Coordinates - Text Entry of Military Grid Reference System (MGRS) Coordinates This is an OCU software requirement that is not in the OCU MPS. The earlier Q&A indicated the Government furnished MOCU software will be V1.3.1 complaint. Can we assume that MOCU will meet this requirement? If not, please clarify. Answer 8: These requirements are not the responsibility of the vendor. Question 9: System Specification 8.3.3 states: Ability to designate points and conduct linear measurement from a 2-D geographic map or the primary (color) video feed; Ability to view and alter vantage point (create third-person views) within a 2-D world map display that includes a representation of the robot and its manipulator; 2-D enhanced telepresence. This is an OCU software requirement that is not in the OCU MPS. The earlier Q&A indicated the Government furnished MOCU software will be V1.3.1 complaint. Can we assume that MOCU will meet this requirement? If not, please clarify. Answer 9: These requirements are not the responsibility of the vendor. Question 10: System Specification 8.3.5 states: Save and retrieve customizable user profiles which specify the "screen view" preferences of the user. Save and retrieve customizable user profiles which specify the robot platform specific preferences of the user. These items include camera positions and manipulator positions. This is an OCU software requirement that is not in the OCU MPS. The earlier Q&A indicated the Government furnished MOCU software will be V1.3.1 complaint. Can we assume that MOCU will meet this requirement? If not, please clarify. Answer 10: These requirements are not the responsibility of the vendor. Question 11: There is confusion in relation to testing and acceptance of the units (both PRM and production). The Government in Answers #10, #16, #33, #66, and #67, states that the PSI is not required to perform any testing. However, many portions of the solicitation contradict this, including: Addenda 17 to 52.212-4, HQ C-2-0027, First Article (Government Testing) (NAVSEA) (SEP 1990), states: "The First Article shall not be delivered... until after the Contractor has fully tested it..." Statement of Work section 1.2, Phase II, "The contractor shall integrate and test AEODRS systems...." Statement of Work, section 3.3, Phase II - Full Rate Production, "The contractor shall fabricate, integrate, test, and deliver production systems..." Further, although Statement of Work section 3.2.18.2 states that "the Government will accept PRMs once... proven to be operational according to contractor supplied setup and functional test procedures", the Government states in Answer #11 that it "will conduct extensive testing". Additionally, the Government states in Answer #10 states: "The Government is not requiring the PSI to perform any testing. However, if the PSI decides to perform any testing on the subsystems, capability modules, or the entire system, then, per section 3.2.14 of the SOW, the Government is requiring the PSI to deliver a test plan that details the planned testing." This implies that it is the offeror/contractors choice whether or not to perform testing and therefore whether or not there will be a contractor supplied functional test procedure. Will the Government please clarify the testing and acceptance criteria and process and modify the solicitation for consistency? Answer 11: This is addressed in the new RFP. Question 12: Regarding 3.2.11 of the Final RFP, Technical Data Package (TDP), request the Government clarify if the intent of the Product TDP is to include pricing of proprietary data from a CM/subsystem provider? If the intent is to capture all information that would allow an independent third party to produce a particular provider's capability module or subsystem, would the Government consider a different arrangement where the required information would be provided only under special circumstances such as default or cessation of business or product line? If the intent of the Product TDP is not to require Proprietary data be priced, request the Government specify what additional information should be supplied in the Product TDP versus the Developmental TDP? Answer 12: The Government is requesting the Contractor to provide the total dollar value for a Level III (Production Level) TDP for the entire system from the PSI level. There is no requirement to break out pricing to the CM/subsystem level. Question 13: Are the requirements of the attached memorandum (Attachment A) applicable to the AEODRS Increment I program, and should the PSI and AB module subcontractors plan for both forward and back-fitting of M-code into all AEODRS Increment I systems delivered to the Government, to include the four (4) PRMs and all production systems? Specifically, will an M-Code capable SAASM device be required in order to comply with the public law referenced in the attached memo? Answer 13: CM-AB MPS will be updated to include the requirement for the integrated SAASM GPS module to have the capability to receive M-Code. Question 14: If after review of Solicitation SOW and the Ver 1.3.1 specification documents, it is determined that the best approach for the Government is to propose an Engineering Change Proposal (ECP) as a part of our proposal, how does the Government recommend we address the notional ECP in our price and technical volume and still remain in compliance with the requirements of the solicitation? Answer 14: Question answered under new RFP. Question 15: If the Government elects to award any Phase II Options on this contract, how long after award are the initial hardware deliveries (production systems, DLRP kits, consumables kits) expected to occur and how long until the last hardware items are delivered on the task order? That is, what are the estimated production quantities that the Government would expect per month, and what would typically be the timeline for delivery of the first set / lot? Answer 15: At this time it is anticipated that the option period would be exercised 24 months after award as long as there are no issues or concerns with the base year. The number of systems to be produced each month is undetermined at this time; however the Government has set a quantity that may be ordered per year. Question 16: "What is the maximum power draw of the data logger which will be plugged into the debug port of the CM-MAS?" Answer 16: The max power for the ADLM is 15W. Question 17: Would the Government please verify the contents of the CM-AB HW reference design documentation; specifically, if the README file list of contents is correct, request the Government provide the missing files. In trying to map the embedded README file to the files contained in the package, we are not getting a match. Our findings are shown on the chart below. We cannot identify the first 4 files listed or file 17, the.gtp file. The PCB file that shows up in Windows explorer is not listed on the README file. Request the Government clarify the file folder contents? Answer 17: "There is content missing as identified. The content will be distributed once it is located. However, the lack of this information should not affect the ability to propose a solution. The primary functions of this small board are twofold. 1.) Tailor incoming configuration data line appropriately for processing on the CM AB main processor I/O lines. 2.) Translate serial data from the KVH fiber optic gyro to serial I/O lines on the main processor The dimension of the boards and the necessary components are given in other.pdf and BOM provided. These can be used as reference materials to inform design approach. Question 18: The prefixes "(T)" and "(O)" in the performance specifications would appear to imply threshold and objective requirements, but there is no definition of these prefixes or reference to different requirement types and how they should be treated in the RFP package. Please clarify the intent of these prefixes and any implications of differing requirement types. Answer 18: (T) and (O) do imply threshold and objective requirements or specifications. A threshold represents the minimum acceptable value for a specific requirement (or in some cases, the maximum acceptable value - e.g. weight). An objective represents the desired goal beyond the threshold. Question 19: I have a question regarding a part listed below. We need more description in order to cost this unit out. What is called out on specs... 12-35 Socket Arrangement MIL-STD-1560B 12 Shell J2, J3, J4, J6, J7 MIL-DTL-38999 12-35 MIL-STD-1560B 12-35 Socket Arrangement This is a GlenAire part. We'll need to know what class and /# i.e. D38999/20W. This will tell the factory what flange type and plating is needed. Answer 19: Any details such as flange type and plating that are not called out in the specs are left up to the PSI to specify for their particular design instantiation. Question 20: (a) Reference CLIN 0019, Phase I Data (page 9). Offeror believes that CDRL A012 (Master Program Schedule) is already covered under CLIN 0002 (Phase I - Master Schedule and Updates) and can be removed from CLIN 0019. (b) Offeror also believes that the reference to CDRL A023 (Consumable Parts List and Updates) should be covered under the Phase II Consumable Parts CLINs 0026 (OYI), 0033 (OYII), 0040 (OYIII) and 0047 (OYIV). (c) Offeror notes that the reference to CDRL A025 under CLIN 0026 should read "CDRL A023" since there was no CDRL A025 provided with the solicitation and CDRL A023 was referenced in SOW Paragraph 3.3.6.2. If the Government concurs with this assessment, Offeror requests that Section B of the solicitation be modified to affect these updates. Answer 20: Addressed in new RFP. 2.Solicitation N00174-13-R-0043, which was suspended on 13 January 2014 prior to the receipt of proposals, is hereby canceled. No additional questions will be taken under this RFP. A synopsis has been posted under N00174-14-R-0006. An RFP is expected under that synopsis later this quarter. 3.Question regarding this amendment should be directed to Omar Roque at omar.roque@navy.mil or 301-744-6607. (End of Summary of Changes)
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/DON/NAVSEA/N00174/N0017413R0043/listing.html)
- Record
- SN03354434-W 20140503/140501235404-afccbcf93bff60f4a20783edf848e6f6 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |