REQUEST FOR INFORMATION FOR PROCUREMENT OF OVERALL PLANNING SYSTEM

Transcription

1 REQUEST FOR INFORMATION FOR PROCUREMENT OF OVERALL PLANNING SYSTEM 1. The Ministry of Defence, Government of India, intends to procure Overall Planning System (OPS) from Indian Vendors. 2. The Request for (RFI) consists of two parts indicated below. Part I. The first part of the RFI incorporates operational characteristics and features that should be met by the equipment. Few important technical parameters of the proposed equipment are also mentioned. Part II. The second part of the RFI states the methodology of seeking response of vendors. Submission of incomplete response format will render the vendor liable for rejection. PART-I 3. The Intended Use of the Equipment (Operational Requirements). The Overall Planning System is intended to encompass all aspects of campaign planning integrating military strategic, operational and tactical levels. 4. Important Operational and Technical. The required operational and technical parameters are placed as Annexure-I. PART-II 5. Procedure for Response (a) Vendors must fill the details as given in Appendix B to chapter II of DPP Apart from filling details about company, details of exact product meeting other generic technical specifications should also be carefully filled as sought in the Annexure-II. Additional literature on the product can also be attached with the form. (b) The filled form should be dispatched at the under mentioned address:- PD Proj Room 408 Air HQ (Vayu Bhavan) Rafi Marg, New Delhi Tele: Extn: 5407 Fax:

2 2 (c) Last date of acceptance of filled form is four weeks from the date of posting of RFI on e-procurement website of GOI/IAF website. Vendors shortlisted for issue of RFP would be intimated. 6. The government of India invites responses to this request only from Original Equipment Manufacturers (OEM)/ Authorised Vendors/Government sponsored Export agencies (applicable in case of countries where domestic laws do not permit direct export by OEMs). The end user of this equipment is Indian Air Force. 7. Quantity. The system shall be designed and developed for IAF alone and the ownership of the OPS will reside with IAF. The software will be hosted from two Data Centers of IAF with active-active configuration in Air Force Network. The system would include the hardware to be deployed at Data Centers. No hardware is envisaged for end users, since they would access the software through browser on AFNET PC. The system shall support 1000 concurrent users. 8. Tentative time schedule for the issue of RFP. The RFP is likely to be issued in the 2 nd quarter of The anticipated timelines for delivery of system is as follows. (a) T months is the duration anticipated in totality for development and deployment of the system. Further, user acceptance and change request will be accepted for Tf +1 year. (b) Consultancy and support for software shall be provided for Tf+5 years (warranty + AMC). Time references are as follows. (i) T0 : Date on which contract is signed. (ii) Tf : Date of deployment of OPS. (iii) Provision for change requests during the period from T0 to Tf +1 year will be provisioned by the vendor. 9. The following points need to be elaborated in the proposal by the firm (a) AMC support across the country. (b) The quality standards like ISO, IEC, etc applicable to the vendor may also be brought out in the proposal. (c) Terms and conditions for warranty support, training support, AMC services; factors determining the cost for all these need to be part of the proposal. (d) The date of induction of the product/ technology offered in the proposal should be quoted. They should also mention whether the product offered is indigenous, whether the complete in-house production/ in house design

3 3 facility of manufacturing units for the proposed software is available in India or not. In case the technology is not available in India the extent of their availability and accessibility needs to be brought out. (e) Previous implementation of the subject project in other sectors may also be brought out to ascertain the credibility of the product. 10. Availability of Overall Planning System in Indian Market, level of indigenization, delivery capability, maintenance support, life time support etc are required to be specified by the vendor. 11. Are any restrictions applicable in the exports (in vendor s country)? If yes, how long is it likely to get clearance? 12. Vendor is to indicate the following in clear terms in their response:- (a) The capability of Indian vendors to indigenously design and develop the required equipment. (b) Applicable key technologies and materials required for manufacturing of the Equipment/System/Platform and the extent of their availability or accessibility, in case they are not available in India. (c) Availability of the equipment/system/platform in the Indian market, level of indigenisation, delivery capability, maintenance support, life time support etc. (d) Approximate cost estimation and suggestions for alternatives to meet the same objective as mentioned in RFI. 13. Vendors who claim to have ownership of design are to certify the following in clear terms in their response:- (a) That the design and development is indigenous and belongs to him/her and/or its Indian sub Vendor/Partner. (b) That the complete set of design and production drawing are available and source code for all software applications/programmes are also available with the Vendors and that these would be produced for verification when required. (c) In addition, these vendors are also to provide details of IPR documentation/ patents/design registration/ copyrights etc registered with authorised agency with regard to the systems/ subsystems where applicable and furnish any other documentation to substantiate their claim on voluntary basis. (d) Undertaking to accept that the failure to prove the claim of ownership of design for (Name of the product) will lead to penalties as may be imposed by MoD.

4 4 14. It may be noted that a detailed verification of compliance to IC (where ever applicable) with reference to claims made by vendors would be carried out during TEC and FET stage. Verification of the cost aspect of IC shall be undertaken at CNC stage. 15. Availability of equipment/system in the Indian market, level of indigenisation, delivery capability, maintenance support, life time support etc are also required to be specified by the vendor. 16. Are any restrictions applicable in the exports (in the vendor s country)? If yes, how long is it likely to get clearance? 17. This information is being issued with no financial commitment and the Ministry of Defence reserves the right to change or vary any part thereof at any stage. The Government of India also reserves the right to withdraw it should it be so necessary at any stage. The acquisition process would be carried out under the provisions of DPP 2016.

5 5 Annexure-I (Refers to Para 4 of RFI) OPERATIONAL REQUIREMENTS FOR OVERALL PLANNING SYSTEM 1 General Overall Planning System (OPS) (a) The proposed system would encompass all aspects of Overall planning integrating all levels of air Overall planning, execution, monitoring and decision support at operational and tactical levels. Provide nomenclature offered system of 2 General Functions (b) The OPS is drawn from IAF doctrine and it envisages automating a major portion of the entire war fighting process in keeping with future requirements. The system should be able to link together the Strategic Operational Tactical levels of air operations. The system would enable Overall planning, monitoring, analysis and decision making by commanders at operational and strategic levels. Provide capability of offered system (a) The OPS must integrate the three levels with the macro level picture being presented at levels higher than Service HQ. The networked system must have the following layers:- 3 General Architecture (i) (ii) (iii) (iv) (v) Database Layer Overall Planning Layer Overall monitoring and Analysis Layer Overall Execution Layer Decision Support Layer Provide architecture details.

6 6 (a) This layer will enable creation of an expanded situational awareness at strategic, operational and tactical levels (b) The database layer should support two models, namely the Intelligence Model and Air Situation Analysis Model for analysis. This would enable commanders to execute two tasks Observe and Orientate of the OODA cycle. (i) Intelligence Model. The Intelligence Model would be the result of all space, time and force factors that affect the Overall in the form of a master database. The model would thus incorporate all intelligence inputs and would be a visual representation of all threats in the AOR. Surface threat models too would form a part of this model as discrete overlays. 4 Database Layer (ii) The planning of the Overall would be totally dependant on the creation of this model as the GIS databases for further planning and execution would be populated accordingly. (iii) Situation Analysis Model. Based on intelligence, the next requirement would be assessment and appreciation. This model would aid in analysis through a Strength, Weakness, Opportunities and Threat (SWOT) process or a similar variant. Vendor to provide details

7 7 5 Overall Planning Layer This layer would be the backbone of all operational level planning. (a) Formulation of Objectives. The first step in the process would be the formulation of the objectives strategy. Maintenance and admin objectives that enable the attainment of op objectives too need concurrent identification and analysis in the OPS. (b) Aspects of Task Development. Once the objectives are identified, then the process of task/target development would start. Task/ Target development is dependent on a number of variables that would be a part of the common GIS databases. The tasks/targets would then be communicated to the combat units in the form of Tasking / Execution orders. Vendor to provide details (c) Support Elements Integration. Combat support and integration of the supporting elements is another critical aspect of Overall planning and conduct. Combat support has to be integrated into the OPS at all levels with the aim of providing the combat units in the field and warfighting commands pro-active support which will aid in planning and task development.

8 8 6 Execution and Monitoring Layer (a) This layer must be designed to enable the range of warfighting activities by combat units with simultaneous monitoring by higher formations. This execution layer must also have a mission planning capability for decentralized operations that are independently tasked to combat units. Vendor to provide details (b) Once the Overall plans are prepared, the system should be able to execute and monitor the progress of the Overall plans. 7 Decision Support layer This layer would apply to higher echelons and would be tailored to support and enable decision making by Commanders at operational and strategic levels. The Commanders decision cycle is a process linking the intelligence and targetting cycles. It would help in reviewing the progress of the Overall plannning, asset allocation, decision making, review of objectives and tasks and so on. Vendor to provide details 8 Operational Requirements (a) The system architecture shall provide for two distinct modes, namely Operations and Training. The Operations Mode must be tailored for actual warfighting/operation and must therefore be simple and robust. The Training Mode of the system would be based on the Operations mode in an expanded form catering for peacetime requirements Vendor to provide details (b) The various interfaces that are required for functioning of the system are as follows:- (i) Overall Planning Interface (ii) Overall Executing and Monitoring Interface (iii) Decision Support Interface

9 9 9 Planning Interface Status of Availability /Non Availability Readiness 10 Execution and Monitoring Interface 11 Decision Support System The features like Intelligence Preparation, Air Situation Analysis, Objective Development Interface, Task Development Interface, Mission Planning for all combat systems Availability, Readiness & Weapons Availability, Crew Availability, Weather Inputs, Weapon to target Matching, Air situation picture Interface, Integration with Combat Enablers, Tasking and Execution Orders, Workflow Integration with surface forces, Mission Display, Radar/ Weapon Platter Display, Ac Data Downloads/Uploads, Satellite Data etc. are are required in this interface. (a) The following features are required in this interface (i) Execution Interface mission launch information, GO/NO GO criteria etc. (ii) Monitoring including provisions for quick engagements of dynamic targets (iii) Residual Combat Potential (iv) Residual Adversary Combat Potential (a) The decision interface would be used to assess the extent of task achievement, tasks left and the effect of enemy air actions to aid the commander in decision making, strategy review and assessment of resource and capability requirements. (b) The interface should consider inputs pertaining to the joint Overall progress. (c) Suitable provisions for feedback to higher echelons would be built into the decision support interface. Vendor to provide details Vendor to provide details Vendor to provide details

10 10 12 Additional Provisions (a) Integrate with user nominated war gaming systems. (b) Integrate with user nominated Planning Tools (c) Artificial Intelligence capable as required (d) Modular system deployable within a zone of conflict with standalone back end support. 13 Training Mode (a) The system in training mode shall provide for definition of exercise boundaries, blue and red forces and their deployment including Army and Naval assets. (b) The software shall also provide for creating targets with geo database for both the forces similar to that in actual operations mode. (c) Supervisory & Umpiring (White Force) capability must be available. (d) Enable a simulation mode wherein events (e.g. weapon launch, destruction of assets, assets shortage, failures etc) can be simulated and transmitted to participating forces (nodes). (e) The system must analyse and derive results/outcome of combat situations in an automated/semi automated manner. (f) The system must allow control of information (status of assets, simulated events, results, contingencies, en state) to participating forces (nodes). (g) The system should have a separate data archival system that should allow detailed storage and restoration of entire exercise data/special missions. From the archival system, a user defined debriefing template is to be structured in the system.

11 11 (h) The system should be able to fly-through a scenario in 2D and 3D. The other functionalities of processing and display of data should be same as that in actual operations mode. In training mode, the software should have provisions to integrate with aircraft download data like combat simulation pods and INGPS for comprehensive debrief with user defined data and hand held GPS tracks. 14 Technical Requirements (a) GIS. The system shall have a common Open GIS Consortium (OGC) compliant Geographical System (GIS) overlay (including 3D) for situational awareness display and man-machine Interface. The projection should be Lambert Conformal Conical to meet the requirement of correct projection. Common geo-spatial database shall be designed and have provision for suitable interfaces with existing and futuristic databases. GIS would aid in transformation of data into information and knowledge to aid in decision making process. It would be based on a common time and geospatial reference framework. (b) GUI. The system shall have user friendly customized graphical user interface. All data entry interfaces have to be so designed / integrated with existing / futuristic systems so that user inputs are taken at only one point and that user is not required to feed same data in different forms / sub-systems. System shall populate all forms with default / known parameters (wherever feasible) to keep the data entry minimal by operators. However there shall be provision for user to change the default values. System shall perform validation of the input data being fed by user such that unviable inputs are not taken and data integrity is maintained. Each layer of system architecture must be capable of pushing or pulling data inputs as necessary. Provide specifications of the offered system.

12 12 (c) Feedback. The system shall provide near real time feedback and have provisions for various reports (GIS overlay as well as text / PDF / graphical). In addition, there shall be the provision of query builder to fetch user defined reports. The user reports should be exportable to MS Office formats. (d) Hardware. The system shall be installed on COTS hardware and would be hosted from User defined network Data Centers in redundant mode with Data Centre- Disaster Recovery mode in Active-Active configuration with live updated database at data centers as well as data recovery. The system front-end should be capable of upgradation with OS changes and hardware upgradation. (e) Users The system shall support at least 1000 concurrent users with configurable idle session time. Provision of live monitoring and management is to be extended to System administrators. (f) Manual Override. The system shall give computer generated outputs, suggestions and alerts with provision of manual over-ride to authorised users. Suitable mobile application to enable feeding of requisite minimal data and forwarding on user customised mobile phones. (g) Overlays. The system should have provision for display of overlays and tote boards with user selectable information, which are automatically updated for display on large screens/data walls.

13 13 (h) Messaging System Interface. The system should have in-built messaging system for sharing of time sensitive information between various users. The information should be pushed to the intended user as per the pre defined time lines and user should always have the updated information as per his appointment/role. (j) Symbols and Overlays. The software shall use standard symbols and colours for depiction of various entities. There shall be a provision to add /modify the symbols and associate it with geo database by the user. 16 Hardware (a) The application should be capable of being hosted in latest Blade servers in Data Centres (DC) and Data Recovery (DR). The data will reside in associated SAN storage which will cater for data redundancy in RAID 5 architecture. The vendor to specify number of servers, SAN along with technical specifications 17 Security (a) Software should be assessed for vulnerabilities/security threats and certified during development and deployment on in house network also subsequently on update / release. The requirements of Integrity, Availability, Traceability, Accessibility, Authentication, IPR etc. Vendor to specify

14 14 18 System Design 19 Total Technical Life (a) The System would be reliable, robust, redundant, user friendly and futuristic. The software shall be based on Model-View- Controller (MVC) architecture. The system would be hosted on a distributed network with both fixed and ephemeral network connection types permitting both centralised decision making at key nodes and distributed synchronized or even autonomous decision making at other nodes/ sub nodes as necessary. To cater for any contingency the system must enable a real time dynamic switch over to any sub node taking over the required functions. (b) The system should be able to follow the protocol and hierarchal setup. Provide need to know information and accessibility at various levels. System to have the self healing capability in terms of automatic configuration of components, automatic discovery and correction of faults and automatic monitoring and control of resources to ensure the optimal functioning with respect to the defined requirements. (c) The system is based on three notionally depicted pillars at each level, namely Functional, Maintenance and Administration. Module based for various functions under each pillar and integrated laterally as well as vertically. The system must have a life of at least 20 years. Vendor to specify

15 15 Maintenance and Technical Specifications S User Requirements Vendor to specify No 1 Obsolescence management aspects. Provide details 2 Product support period, AMC and such maintenance Provide details issues. 3 Exceeding 72 hrs and cumulative downtime not exceeding 25 days per annum during the warranty period. The vendor shall ensure that adequate spares are stocked at site free of cost to meet the stipulated availability requirements. The vendor shall position a suitably qualified Field Engineer at Deployment site throughout the warranty period for prompt rectification of faults. 4 Provision of comprehensive AMC (i.e. inclusive of all spares, consumables, major preventive maintenance of hardware, breakdown maintenance and obsolescence management) Give details including Rough cost of AMC post expiry of warranty throughout the entire product life cycle. Entering into the AMC would be at the discretion of IAF. The cost of the AMC will be given due consideration during the product finalization phase. 5 Training of instructors, operators and technicians to enable Give details conduct of O level maintenance. 6 Facility for upgradation in future (open architecture). Give details 7 Supply of all operational and maintenance Give details documents/publications. 8 System Installation Hardware / Software and Give details commissioning. Any other relevant and additional information on capability may also be specified.

16 16 INFORMATION PROFORMA (INDIAN VENDORS) 1. Name of the Vendor/Company/Firm. Annexure-II (Refers to Para 5 of RFI) (Company profile, in brief, to be attached) 2. Type(Tick the relevant category). Original Equipment Manufacturer (OEM) Authorised Vendor of foreign Firm Others (give specific details) Yes/No Yes/No (attach details, if yes) 3. Contact Details. Postal Address: City: Pin Code: Fax: State: Tele: URL / Web Site 4. Local Branch/Liaison Office in Delhi (if any). Name &Address: Pin code: Tel: Fax: 5. Financial Details. (a) Category of Industry (Large/medium/small Scale): (b) Annual turnover: (in INR) (c) Number of employees in firm: (d) Details of manufacturing infrastructure: (e) Earlier contracts with Indian Ministry of Defence/Government agencies:

17 17 Contract Number Equipment Quantity Cost 6. Certification by Quality Assurance Organisation. Name Agency of Certification Applicable from (Date &Year ) Valid till ( Date &Year) 7. Details of Registration. Agency DGS&D Registration Validity(Date) Equipment DGQA/DGAQA/DGNAI OFB DRDO Any other Government Agency 8. Membership of FICCI /ASSOCHAM /CII or other Industrial Associations. Name of Organisation Membership Number 9. Equipment/Product Profile (to be submitted for each product separately) (a) Name of Product: (IDDM Capability be indicated against the product) (Should be given category wise for e.g. all products under night vision devices to be mentioned together) (b) (c) (d) (attach technical literature): Whether OEM or Integrator: Name and address of foreign collaborator (if any):

18 18 (e) (f) (g) Industrial Licence Number: Indigenous component of the product (in percentage): Status (in service /design & development stage): (h) Production capacity per annum: (j) Countries/agencies where equipment supplied earlier (give details of quantity supplied): (k) Estimated price of the equipment Alternatives for meeting the objectives of the equipment set forth in the RFI. 11. Any other relevant information: 12. Declaration. It is certified that the above information is true and any change will be intimated at the earliest. (Para 44 and Appendix F to Chapter II may be referred) (Authorised Signatory)