Proof and trial activity in a dynamic test range is a complex, sensitive, and herculean activity. It is a system comprising critical functions that accept various armament inputs and produces proof results as output, processing various critical data and sensitive activities in between. Automation of the existing system is a step for reliable, secure, smooth operation and easy maintainability of the system that makes it synchronized with the latest development of range technology. Understanding the flow of data through these functions requires extensive study to realize different inter-linked activities involved with the functions of this system. This paper presents the flow of activities in the automation of dynamic test range of Proof & Experimental Establishment through context level diagram, process flow diagram, data flow diagram, and entity-relationship diagram. Realization of armament integrated management system will be through resilient and high bandwidth network backbone which is a part of this paper. Cloud computing is the latest development in the information technology. This paper also analyses the appropriate model of cloud computing for porting the system in the cloud.

Keywords:    Context level diagram,  process flow diagram,  data flow diagram,  distributed architecture,  cloud computing,  armament integrated management system

Proof & Experimental Establishment (PXE) is involved in dynamic test and evaluation of armament stores where numerous entities are involved. The activity starts with the receipt of armament stores from the external agency, followed by preparation of store receipt intimation, proof detail, floating the proof detail to various entities involved in the firing activity, coordinating various tasks involved in the firing, storage, retrieval, and processing of firing data, reports generation, and finally ends with the successful completion of activity, with dispatch of firing results to the relevant external agency. At present, isolated software modules using distributed architecture are used¹. There is a requirement of an integrated software module which can centralise all the isolated modules with minimal data redundancy and less paper-driven work.

The objective of armament integrated management system (AIMS) is design, development, testing and implementation of a graphical user interface (GUI)-based software that will interlink different entities to automate the overall dynamic test and evaluation process, starting from inception of armament stores to generation of final reports through storage, retrieval and processing the pre- and post-firing data. AIMS optimises the running processes in and between entities, reduce data redundancy and ensure concurrency using centralised database. It is event-driven so that trial processes are implemented in a streamline manner effectively. Access right for data is implemented so that only authorized user of the respective entities can access the data pertaining to their rights only. System administrator has access to all the data using passphrase. The software deals with proof/trial details of the armament stores, and hence, very sensitive in nature. A strong security mechanism has been incorporated in the system to protect unauthorized access of the data.

The design and development of AIMS follows the iterative waterfall model of software development life cycle (SDLC). The design phase of AIMS consists of software requirement specifications, process flow diagram, context diagram of the overall system and the sub-systems. The sub-systems of the AIMS also comprise data flow diagram and entity-relationship diagram apart from the process flow diagram and context diagram.

Software requirement specifications (SRS) plays an important role in the analysis phase of SDLC. It collects customers requirements and systematically organises them into a specification document². It provides detailed information of the entire software wrt users’ requirements. In AIMS, SRS document collects and analyses all the requirements of users and writes these in a systematic and structured way. It is the final outcome of the requirements analysis and specification phase. It presents a general description of the project with the functional, non-functional requirements and goals of implementation with required hardware interfaces, software interfaces, communication interfaces, memory constraints, etc. It also takes care of product functions, logic, user characteristics, constraints, assumptions and dependencies. Specific requirements contain use-case-documentation, performance requirements, and design constraints with reliability, availability, security, and maintainability. Supporting information section signifies prioritisation, release plan, etc. In a nutshell it is the brief, consistent, unambiguous, and complete document³.

A context diagram is a high-level logical approach for efficient and systematic design and development of a software product to clearly define system and its environment by interacting between its entities. Context diagram is further grouped into sub-systems to represent the complete system in an organised way⁴. Figure 1 shows the highest level of abstraction of AIMS to clearly depict the scenario where the other sub-systems are interacting with it. AIMS comprises of 17 dynamic entities which directly participate in the system. The interaction starts with the ammunition (AMMN) entity, which participates in the events like receipt of ammunition, receipt of Firing Program (FP), receipt of Proof Details (PD), preparation of Store Receipt Intimation (SRI) and Internal Issue Voucher (IIV), generation of monthly expiry report, sending burning certificate and disposal instructions to the concerned authority, respectively. Ammunition Preparation (APW) entity receives FP and PD and executes the events like sending Internal Issue Voucher Return (IIVR), forwarding After Firing (AF) and Before Firing (BF) measurement of the fired projectiles. It forwards trial result to Firing Planning and Coordination Cell (FPCC), which is directly involved in generation of FP after receiving PD and SRI. Trial and Evaluation (TE)/Proof and Ballistic (PB) entity generates PD and sends compiled result as well as backloading instructions after receiving and executing FP. Weapon entity too forwards SRI and receives FP and PD. Range entity receives FP and PD and is responsible for sending After Firing Recovery Report. Instrument entity provides instrument/environmental conditioning chamber status, firing result after getting FP and PD. General Store (GS) directly communicates armour-plate issued info and SRI to the system. The workculture of Naval Armament Depot (NAD) is just like AMMN and Weapon Entity. Naval Proof and Trial (NPT) acts like TE/PB Entity. Both NAD and NPT focus in the field of Naval Trials. Computer and networking systems group (CNSG) plays a vital role in the system by executing the role of a system administrator as well as database administrator. The role of external agency is to release proof report and proof sample details and to receive Nominal Issue Voucher (NIV), compiled result and Issue Voucher (IV). This overall context diagram represents the system as a whole whereas the individual 17 other sub-systems are also elaborated in their subsequent context diagrams.

Process Flow Diagram is a technique referred in the software requirement analysis phase of SDLC⁵. It decomposes a system with all its processes, input data, output data, and their systematic flow in the system⁶. It does not incorporate the inconsequential details of the processes. In AIMS, the overall Process Flow Diagram is graphically represented in Fig. 2. Diagram shows a clear understanding of all the processes that finally facilitate with required output from the system. The different entities are grouped together as per their similar job roles are presented in the diagram accordingly. Diagram illustrates that external entity is involved in sending annual production program and annual requirement for proof and trial purpose. It receives quarterly requirement for the same purpose. It sends trial information and receives trial result also. TE/PB/NPT analyses the feasibility of the firing requirement spelt out by the external agency and finally prepares Proof Details and sends related trial result to the external agency. Instrument (INST)/High speed image photonic (HIP)/Meteorology (MET)/Survey (SURV) provides logistic support for the dynamic proof and trial work. It ends up with forwarding the processed trial result to TE/PB/NPT. AMMN and Naval Armament Depot (NAD) are responsible for optimized receipt and issue of ammunitions. AMMN provides service to Army whereas NAD gives services to Navy. FPCC generates Firing Program after receiving proof details from concerned entities. It also receives Store Receipt Intimation (SRI) report from AMMN/NAD entities. WEAPON/APW/Communication (COMMN)/Range Survey (RSD)/RANGE/GS receives Proof Details and acts accordingly to conduct dynamic proof and trial successfully. CNSG being a system and database administrator, performs recovery of data, backup of data, record of logs, fine-tuning of database and also forwarding request for reprint of PD/FP to the concerned entity. The corresponding individual process flow diagrams of the entities are drilled down for better understanding of the sub-systems. The total number of process flow diagrams in AIMS is 17.

Data Flow Diagram (DFD) is a graphical representation of the system used in the analysis and design phase of SDLC⁷. It clearly represents a system with systematic flow of input and output data and their storage. AIMS consists of DFDs of different entities to understand the system in a systematic and methodical way. It simply provides the detailed representation of the processes. This system has 17 entities where each of the entities has different level of detailed Data Flow Diagram. Again, all the 17 DFDs have their own set of Level 0, Level 1, Level 2 diagrams to clearly illustrate the inner process, input data, output data, and their storage. In this paper, only the DFDs related to TE/PB entity are being discussed. TE/PB entity is responsible for different activities like generation of PD, receipt of FP and SRI. It actively involves itself in the process of forwarding burning/demolition/disposal/backloading instructions to the concerned authority. It receives report on recovered shells after firing. This entity also executes, analyses and forwards trial related results to the designated external entity. The details related to the data flow of TE/PB are shown in Fig. 3. Total numbers of data flow diagrams in AIMS is 49.

Entity-relationship Diagram (ERD) is a graphical representation of entities and their relationship to each other. It is a data model using a set of construct and rules. It formally specifies the definition, convention, and use of the role construct⁸. AIMS comprises 17 number of ERDs to represent the system in a systematic way. It conceptualises AIMS database design in a methodical way. It delivers an exact representation of the data content, structure, and constraints required by AIMS.

The distributed architecture comprises client/server and three-tiered interface⁹. In client/server architecture, client and server modules communicate through standardised, abstract interfaces, and behave like an integrated application system¹⁰. Each module is therefore shareable and reusable and can be included in other application systems. In three-tiered architecture, application components lie between the user and the back-end, and communicate with them as shown in Fig. 4. It is easy to deploy because the client is simple and logic is centralised. In three-tiered systems, programmers who have excellent user interface skills can concentrate on developing powerful presentation components, and they do not need to know about the inner workings of the applications. Meanwhile database analysts, who know the best ways to access data from a database do not need to be concerned with how the data is presented to an end user. System analysts and programmers can concentrate on developing algorithms and coding. In AIMS, both client/server and three-tiered architecture is used. Data Manipulation Language (DML) intrinsic modules are developed using client/server architecture whereas view related modules are developed using three-tiered architecture. Storage of data is common to client /server as well to the three-tiered architecture-based modules. This strategy is used to ensure consistency and minimal redundancy in data.

Cloud computing is a distributed architecture-based computing service where different services such as servers, storage and applications are delivered¹¹. It has the ability to provide on-demand service provisioning, scalability and flexibility. It focuses on maximising the effectiveness of the shared resources and dynamically reallocates these as per the demand. Tehnologies extensively used in cloud computing are virtulisation, distributed architecture, high-speed computing and information security. In AIMS software-as-a-service (SaaS) the model of private cloud would be used. This will help Resource Pooling where resources are pooled to serve multiple entities using multitenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. It will also provide rapid elasticity, the resources can be elastically provisioned and released automatically and scale rapidly where outward and inward consumer rates with demand.

As discussed in previous sections that the basic objective of AIMS is to transmit various firing related data from different firing locations to the centralised server for storage, retrieval, and processing of firing results and generation of reports. For faster transmission of data to the centralised server realisation of “Resilient Network backbone” is undertaken. The resilient network will have 10 Gbps backbone connection with ring topology with zero point failure. It will be robust, having low latency, fast convergence, high scalability, single point management, i.e., Software-defined networking (SDN), highly secured with authentication-authorization-accounting (AAA) server and IPV6 compliance. It will be equipped with Software-defined networking features that will provide single point management and also will have facility to build up cloud application on this network backbone. The schematic diagram of the network is shown Fig. 5.

The main idea of designing AIMS is to create a well-defined and structured process for all entities to function in a coherent manner with the overall objective of lowering data redundancy, optimizing data storage, enhancing workflow management, increase data mining capabilities and achieve complete process automation. Systematic and methodological SDLC approach has been taken care for smooth design, development and execution of this software. Realization of resilient network backbone is included for faster transmission of data. The concept of distributed architecture and cloud computing is appreciated by keeping pace with recent and upcoming technologies.

1. Das Gupta, P. K. & Mondal, R. Developing web applications using ASP .NET and Oracle, (Ed.2). PHI Learning Pvt. Ltd, New Delhi, 2013, pp.342-426.

2. Rajib, Mall. Fundamentals of Software Engineering. (Ed.3). PHI Learning Pvt. Ltd, New Delhi, 2009. pp.108-109.

3. Thongglin, K.; Cardey, S. & Greenfields, P. Thai software requirements specification pattern. In Proceedings of 12th IEEE International Conference on Intelligent Software Methodologies, Tools and Techniques, 22-24 September 2013, Budapest, Hungary. pp.179-184.

4. Sarma, A. D. N.; Siva, Rama Prasad R. & Sarma, A. R. C. Representation of functional architecture for operational business intelligence system. In Proceedings of the International Conference for Advances in Engineering, Science and Management (ICAESM), 30-31 March 2012, Nagapattinam, Tamil Nadu. pp.213-218.

5. McInnes, I. A.; McInnes, K. B. & Grover, R. Formalising functional flow block diagrams using process algebra and metamodels. Int. J. IEEE Trans. Sys., Man Cyber., Part A: Sys. Humans, 2011, 41(1), 34-49. [Full text via CrossRef]

6. Adler, M. An algebra for Data flow diagram process decomposition. Int. J. IEEE Trans. Software Engg., 1988, 14(2), 169-183. [Full text via CrossRef]

7. Ward, T. P. The transformation schema: An extension of the data flow diagram to represent control and timing. Int. J. IEEE Trans. Software Engg.,1986, 12(2), 198-210. [Full text via CrossRef]

8. Davis, J. P. & Bonnell Ronald, D. Role Representation in the E-R data. In Proceedings of the IEEE International Conference for Energy and Information Technologies in the Southeast, 09-12 Apr 1989, Columbia, SC, 3. pp.1106-1110. [Full text via CrossRef]

9. Das Gupta, P. K. & Radha Krishna, P. Database management system Oracle SQL and PL/SQL, (Ed.2). PHI Learning Pvt. Ltd, New Delhi, 2013. pp.321-350.

10. George, B. V.; Raghavan, R. V.; Pooja, S. & Agarwal, N. K. Distributed computing and its scope in defence applications. Def. Sci. J., 2005, 55(4), 477-485. [Full text PDF]

11. Das Gupta, P. K.; Nayak, M. & Pattnaik, S. Cloud computing: based projects using distributed architecture. PHI Learning Pvt. Ltd, New Delhi, 2012. pp.1-11.