SI2 Questions and Answers to post.xlsx
XLSX spreadsheet 18 KB Posted
- Attached to
- Spider Increment 2 Synopsis
- Solicitation number
- W15QKN12R0059
About this file
SI2 Questions and Answers
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet2
| Question | Government Response |
| To reduce cost and aid in potential reuse, will the Government make available the source code currently implemented in the Increment 1 RCU? | The Government will provide the Increment 1 RCU source code to the Spider Increment 2 contractor after contract award. |
| Request a copy of the Joint Battle Command JBC (JBC) Platform Development Kit (PDK), which was referred to in the Network Munitions Controller Assessment. | The Government will provide the JBC PDK to the Spider Increment 2 contractor after contract award. Interface documentation will be provided to cleared potential offerors prior to RFP release. |
| Section 3.4.2 Software Safety of the draft SOW states: |
“In accordance with JSSSEH Appendix D and E, software that is considered as safety critical shall be developed to isolate the safety critical functionality.”
Section 3.4.2.1 Safety Critical Software Development of the draft SOW discusses two classes of safety software: safety critical and safety related.
In the Increment 1 Software Requirements Specification for the Man-In-The-Loop (MITL) Remote Control Unit (RCU) Tactical CSCI, safety requirements are ranked from I to III with the following definition:
I. Highly Critical – Item is directly related to a hazard or generic safety requirement.
II. Critical – Item is indirectly related to a hazard or generic safety requirement.
III. Low Criticality – Item is marginally related to a hazard or generic safety requirement or a safety mitigation For Spider Increment 2, how are the designation “safety critical” and “safety related” related to the above ranking. For example, does
• Does the “safety critical” functionality referred to in the draft SOW correspond only to safety ranking “I. Highly critical”?
• Does the “safety related” functionality in the draft SOW correspond to the safety rankings” “II Critical” and “III Low criticality”?
The definitions that apply to the terms "safety critical" and "safety related" used in the draft SOW are contained in the JSSSEH and MIL-STD 882E, as follows:
"Safety-critical. A term applied to a condition, event, operation, process, or item whose mishap severity consequence is either Catastrophic or Critical (e.g., safety-critical function, safety-critical path, and safety-critical component).
Safety-critical function (SCF). A function whose failure to operate or incorrect operation will directly result in a mishap of either Catastrophic or Critical severity.
Safety-related. A term applied to a condition, event, operation, process, or item whose mishap severity consequence is either Marginal or Negligible."
There is no direct link between Spider increment 1's Safety Critical rankings of I-III and the JSSSEH/MIL STD 882's classification of Safety Critical and Safety Related. Spider 1 ranks are based on the software's relation to a hazard or generic safety requirements (direct, indirect, or marginally related) regardless of the severity of the hazard. The JSSSEH/MIL STD 882D are based on the severity of the hazard that the software contributes to or mitigates, regardless of how direct the relation between the software and hazard is. The classification of the software requirements (being Safety Critical or Safety Related according to the JSSEH and MIL STD 882) for Spider 1a will be determined by the Software and System Safety Working Group IPTs.
| Does a User Manual or Training Package exist for Spider I RCU and if so, can this be made available to the bidders prior to the RFP release? | The Government will provide the Spider Increment 1 Training Support Package to cleared potential offerors that submit a request to procurement. | ||
| Para. | Requirement | Question | Government Response |
| 3.1.1 | The SI2 RCU shall provide the operator with a touch screen interface for primary and secondary means of entering data and executing commands. A secondary interface should be provided and available given a failure of the primary. | Why is the touch screen interface listed as both the primary and secondary means of entering data and then the requirement specifies a secondary interface should be provided? Seems like the touch screen should be identified as only the primary means. | Concur. The requirement will be modified to read: "The SI2 RCU shall provide the operator with both a primary and secondary means of entering data and executing commands. The primary means shall be via touch-screen, and the secondary means shall be provided and available given user preference and/or failure of the primary means." |
| 3.1.3 | The SI2 system execution of manual fire commands shall be near instantaneous and not exceed 3 seconds. | SI2 uses the SI1 communications system and the contractor has been directed not to change the RCUT, antenna or MCU. The RCU can minimize delays for processing messages and sending them to the RCUT, but that is the only contribution it makes to the command execution time. How can the RCU be expected to achieve this requirement? | SI1 can reliably meet this requirement. The SI2 development effort cannot hinder or slow down the execution of the fire command beyond this requirement. |
Agree with assumption in question.
3.1.3 The SI2 system transmission, acknowledgement, execution, and affirmation of any command shall not exceed 10 seconds. SI2 uses the SI1 communications system and the contractor has been directed not to change the RCUT, antenna or MCU. The RCU can minimize delays for processing messages and sending/receiving them to/from the RCUT, but that is the only contribution it makes to the command execution time. How can the RCU be expected to achieve this requirement? SI1 can reliably meet this requirement. The SI2 development effort cannot hinder or slow down the command and control time beyond this requirement.
Agree with assumption in question.
| 3.1.4.2 | Time to regain control shall begin once a spare or additional RCU is available at the area of operation. | This should not be a requirement. The “shall” should be changed to a “will” since the statement is clarifying the reference for the time measurement. | Concur. This statement is intended to clarify the requirement. PRD will be modified from "shall" to "will". |
| 3.1.4.3 | The SI2 RCS shall provide an Over-The-Air-Transfer (OTAT) command and associated functionality that allows the operator to transfer control of the field/obstacle to another RCS. | What is meant by “another RCS”? Is it another SI2 RCS? | Yes. Over-the-air transfer of control from one SI2 RCS to another SI2 RCS. |
| 3.1.4.3 | The SI2 RCS OTAT to another RCS shall be achieved without the need for physical co-location of the gaining and losing operators. | What is meant by “another RCS”? Is it another SI2 RCS? | Yes. Over-the-air transfer of control from one SI2 RCS to another SI2 RCS. |
| 3.1.4.5 | The SI2 RCU shall provide the operator with the ability to place an emplaced field/obstacle of MCUs into a Power Save Mode. | Currently there is no “Power Save Mode” defined for SI1 components. The radio can be placed in a Sleep state by the RCU operator. The SOW directs the contractor not to change the SI1 system other than the RCU. Is the “Power Save Mode” a future capability or is it the same as the current Sleep state? | Field Power Save Mode is synonymous with SI1 Sleep State. |
| 3.1.4.7 | Pre-formation shall increase system effectiveness by providing tactics such as lethal vs. non-lethal, ammo preservation, AV vs. AP, and the type of AV effect. | This should not be a requirement. The RCU cannot increase system effectiveness. The RCU can only form groups and implement tactics. The effectiveness of the tactics using the groups is not related to the RCU. If pre-formation does not increase system effectiveness, the contractor will not be able to provide corrective action since the contractor is not responsible for the tactics. | The SI2 system will be considered more effective if, by implementing selective pre-formed engagement TTPs, the system enables employing force to preserve ammo, reduce non-combatant casualties, and/or provide a more tailored and timely response to threat incursions. |
| 3.1.4.7 | The SI2 RCU shall be capable of selecting alerted MCUs, individual or pre-formed engagement TTP to fire their associated munitions. | What is an “alerted MCU”? What is meant by the wording “or pre-formed engagement TTP”? | An "alerted MCU" is considered one which has reported a trip. "Pre-Formed Engagement TTPs" will be products of the contractor's solution which enables user-friendly means of pre-configuring and grouping MCUs and effects to better tailor operator manual engagement against threat incursions. |
| 3.1.6 | The SI2 RCU shall provide an interoperable, standard, and shareable geospatial foundation using data models and applications; standard geospatial formats, services, and metadata; as well as update dissemination and management tools (to include formatting) in accordance with the Army Geospatial Center (AGC) and ASA(ALT) Common Operating Environment (COE) guidance. | This requirement seems excessive for a munition controller and more in line with an enterprise server application in the Army’s Common Operating Environment architecture as described in Table 1 of the Common Operating Environment Architecture Appendix C to Guidance for ‘End State’ Army Enterprise Network Architecture. Also this requirement is not consistent with the guidance provided during Industry Day (chart 56 of Spider Increment 2 Industry Day.pdf). What is the intent of this requirement? | The intent of the requirement is to ensure that the Spider Increment 2 solution is in accordance with the ASA(ALT) COE guidance. The requirement is not intended to imply that Spider Increment 2 should implement the entire ASA(ALT) COE geospatial spectrum, only that when the specific Spider Increment 2 solution is implemented (for example, selection of a specific format for the digitized map background) it is done in accordance with AGC and ASA(ALT) guidance. This also applies to the methodology used to receive geospatial updates. There is no discrepancy between what the Spider Increment 2 requirement is and what was presented at Industry Day. |
| 3.1.6 | The SI2 RCU mapping capability shall allow the operator to pan and zoom to TBD levels allowing for grid reference to change according to zoom level (From 1km gridline spacing to 10m gridline spacing when zoomed in). | What is the TBD? The requirement could be reworded to say “The SI2 RCU mapping capability shall allow the operator to pan and zoom to multiple levels as determine through User assessment allowing for …”. This would allow the contractors to state scope the zoom levels within an IPT (C2 or System Engineering). | Concur. That was the intent; to resolve this TBD in an IPT setting. |
| 3.11.7 | Internal batteries, if used, shall be designed to have a manual switch to control power. | The RCU platform will most likely have an internal clock battery that will not have a manual switch. Does this requirement only apply to the main power to the platform? | This refers to any alternative power supplies used to run the RCS. This does not refer to RCU internal battery. This PRD requirement has been modified. |
| 3.11.9.4 | While in the Maintenance mode, the components shall retain all current mission and crypto data history. | What are the “components” (SI1, SI2) referred to in the requirement? The SI1 components do not meet this requirement and contractors have been told not to change the MCUs. | Concur. This requirement has been deleted. |
| 3.11.9.4 | The SI2 RCU shall incorporate a timer which limits the amount of time to 12 hours that a component can remain in a Maintenance mode. | Why does the RCU have a timer? The timer in the RCU cannot by itself limit the amount of time that a component can remain in a Maintenance mode unless the RCU automatically transitions the components out of the Maintenance mode. Otherwise, the timer can only notify the operator that the 12-hour time limit is approaching. SI1 components do not have a Maintenance mode timer. | Concur. This requirement has been deleted. |
| 3.11.9.4 | Upon expiration of the Maintenance mode timer specified in SI2346, the SI2 system component shall automatically transition to the “recovery” state. | What is meant by the “recovery” state? How do the components automatically transition without a maintenance mode timer? What is meant by “SI2346”? | Concur. This requirement has been deleted. |
| 3.11.9.5 | The SI2 RCU shall allow the operator to maintain accurate, reliable, and current information regarding the status and operational condition of all SI2 developed field components. The SI2 RCU probability of inaccurate status display shall be 10e-5 or less. | Does “status and operational condition” and associated probability for inaccurate status display include typical safety critical data such as the state of the field and also typical non-safety critical data such as remaining battery life? Does this requirement only apply to “SI2 developed field components”, i.e., future capability? This requirement can have a significant impact on scope of the SI2 program since a FMECA would be required on non-safety critical software to assess compliance with this requirement. Given the amount of non-safety critical software, it is unlikely that the requirement can be achieved. | The measurable requirement for SI2 RCU to provide a probability of inaccurate status display of 10e-5 is an objective requirement and should be treated as such. PRD has been changed to indicate an objective. |
The false display of safe requirement is a threshold and takes precedence over any objective requirement for displayed status accuracy. Authoritatively displaying Field level Safety Status should not be confused with the objective requirement. We specifically require the state of the obstacle level to have the probability of a false safe display on the RCU be less than 1x10-6 (or in the case of a joint probability - no individual indicator will have a false display of safe greater than 10e-4).
The overall safety design should provide a higher confidence of accurately displaying safety related or mission critical faults or warnings which require an action by the operator to resolve. The intent of the objective requirement is to limit/reduce the impact of false displays of hazards (i.e. inaccurate status display).
This requirement applies to "SI2 field components". The word "developed" has been removed.
| 3.13.2 | “performance requirements IAW 3.13.3.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3 (environmental table) |
| 3.13.3.2 | “performance requirements IAW 3.13.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3 (environmental table) |
| 3.14.1 | The SI2 RCU shall support live, virtual, and constructive training environments in the current force. The SI2 embedded training software will have a fixed number of combat vignettes for the operator to train specific (canned) scenarios. | How many combat vignettes are required? The number of vignettes impacts the scope of the SI2 program. The only guidance to the number of vignettes was in the Industry Day presentation (charts 34-36 of Spider Increment 2 Industry Day.pdf) where three (3) “vignettes” were discussed for SI2. Barring any clarification to this requirement, the assumption would be that three (3) is the number of vignettes desired by the Government. | TBD. The intent to resolve this in an IPT setting. For planning purposes assume 3-10 depending on the fidelity of each. |
| 3.17.2 | The SI2 RCU shall be capable of providing protection throughout its lifecycle from pack-out to demilitarization. | Should this be worded” The SI2 RCU packaging and associated inner packaging shall be….”? | This requirement has been deleted. |
| N/A | Several course of actions in the Industry Day briefing and Controller Assessment utilize the Rifleman Radio. Can it be assumed that Rifleman radios (or equivalent) will be the standard issued to the soldiers operating the Spider 2 system? | Concur with assumption. | |
| 3.12.7 | The SI2 RCU shall not exceed 10m when appropriately camouflaged and viewed against a background of vegetated terrain ranging in color from dark green to light brown, using the unaided eye (20-20 vision). | Is this worded correctly? Should it be worded “The detection range of the SI2 RCU shall…”? | This requirement has been modified. This section now reads as follows: |
"The SI2 RCU shall not cause visual detection due to noise, light emission or exposure greater than SI1. Black out mode can be added to maintain light discipline and low visual detectability."
| 3.13.2 | The packaged SI2 RCU shall remain safe and reliable as a result of exposure to the TREE environments IAW QSTAG 244. | Is this requirement necessary? This is a new requirement on the Spider system and only targeted to the SI2 RCU. The SI2 RCU will replace the SI1 RCU in the RCS Shipping Container. This requirement requires the contractor to determine if the current protection provided by the RCS Shipping Container is adequate and if not to augment the protection or develop another shipper container that would provide the protection. This has the potential to add significant scope into the SI2 program. | This requirement has been removed from the PRD. |
| 3.13.2 | “performance requirements IAW 3.13.3.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3. |
| 3.13.3.2 | “performance requirements IAW 3.13.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3. |
| 3.14.1 | The SI2 RCU shall support live, virtual, and constructive training environments in the current force. The SI2 embedded training software will have a fixed number of combat vignettes for the operator to train specific (canned) scenarios. | How many combat vignettes are required? The number of vignettes impacts the scope of the SI2 program. The only guidance to the number of vignettes was in the Industry Day presentation (charts 34-36 of Spider Increment 2 Industry Day.pdf) where three (3) “vignettes” were discussed for SI2. Barring any clarification to this requirement, the assumption would be that three (3) is the number of vignettes desired by the Government. | TBD. The intent to resolve this in an IPT setting. For planning purposes assume 3-10 depending on the fidelity of each. |
| 3.17.2 | The SI2 RCU shall be capable of providing protection throughout its lifecycle from pack-out to demilitarization. | Should this be worded” The SI2 RCU packaging and associated inner packaging shall be….”? | This is no longer a PRD requirement and has been removed from the current PRD. |
| Several course of actions in the Industry Day briefing and Controller Assessment utilize the Rifleman Radio. Can it be assumed that Rifleman radios (or equivalent) will be the standard issued to the soldiers operating the Spider 2 system? | For the purposes of this RFP, I believe that it is a safe assumption that the Rifleman Radio will be common. | ||
| The Industry Day information (Spider Increment 2 Industry Day.pdf and Networked Munitions Controller Assessment 11 July.pdf) refers to the Real Time Safety Critical Computing Environment as the appropriate category for the Spider Increment 2 system within the Army’s Common Operating Environment. The Government has not provided any specifics regarding the requirements imposed by this category. Key issues are the mapping capability required and any additional safety requirements beyond those imposed in the PRD. A web search does not produce any useful information. Without further information we will have to proceed based on the PRD requirements. Can the Government provide information to clarify the impact of the Real Time Safety Critical Computing Environment on the Spider Increment 2 system? | The standards for the RTSCE CE are under development, and will not be available for RFP. The PRD requirements should be used. In addition, the RTSCE Standards that will be relevant to Spider Increment 2 will be based on the Spider Increment 1 standards, which have been provided. | ||
| It is understood that the SI2 RCU must host embedded training; however, it is not clear from Section 3.14 of the PRD if embedded training material is developed by the SI2 contractor or if it is GFE. Please clarify. |
| The SI2 Embedded Training capability is to developed by the Spider Increment 2 contractor. | |||
| 3.12.7 | The SI2 RCU shall not exceed 10m when appropriately camouflaged and viewed against a background of vegetated terrain ranging in color from dark green to light brown, using the unaided eye (20-20 vision). | Is this worded correctly? Should it be worded “The detection range of the SI2 RCU shall…”? | This requirement has been modified. This section now reads as follows: |
"The SI2 RCU shall not cause visual detection due to noise, light emission or exposure greater than SI1. Black out mode can be added to maintain light discipline and low visual detectability."
| 3.13.2 | The packaged SI2 RCU shall remain safe and reliable as a result of exposure to the TREE environments IAW QSTAG 244. | Is this requirement necessary? This is a new requirement on the Spider system and only targeted to the SI2 RCU. The SI2 RCU will replace the SI1 RCU in the RCS Shipping Container. This requirement requires the contractor to determine if the current protection provided by the RCS Shipping Container is adequate and if not to augment the protection or develop another shipper container that would provide the protection. This has the potential to add significant scope into the SI2 program. | This requirement has been removed from the PRD. |
| 3.13.2 | “performance requirements IAW 3.13.3.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3. |
| 3.13.3.2 | “performance requirements IAW 3.13.2.3” | Referenced paragraph does not exist. What is the correct referenced paragraph? | The correct reference is section 3.13.3.3. |
| 3.14.1 | The SI2 RCU shall support live, virtual, and constructive training environments in the current force. The SI2 embedded training software will have a fixed number of combat vignettes for the operator to train specific (canned) scenarios. | How many combat vignettes are required? The number of vignettes impacts the scope of the SI2 program. The only guidance to the number of vignettes was in the Industry Day presentation (charts 34-36 of Spider Increment 2 Industry Day.pdf) where three (3) “vignettes” were discussed for SI2. Barring any clarification to this requirement, the assumption would be that three (3) is the number of vignettes desired by the Government. | TBD. The intent to resolve this in an IPT setting. For planning purposes assume 3-10 depending on the fidelity of each. |
Sheet3
File details come from the government source that posted it. Updated .