SUPPORTING THE FUTURE FORCE
Furthermore, JWARN’s ability to overlay graphical depictions of those CBRN events onto a command-and-control map that also shows the locations of friendly forces, as well as neutral (non- participating) units or known threats, is of utmost importance for an operational commander who needs to understand the tactical significance of a CBRN event and decide what to do next. Te personnel managing a CBRN incident might only be concerned about events occurring in their immediate area of responsibility, but the cloud-based implementation of JEM and JWARN allows users to track events worldwide.
Each service operates in a different environment and with differ- ent constraints, with the result that each has developed its own command-and-control architecture tailored to its unique needs. Te Army uses more robust command posts, complete with tactical servers dedicated to maintaining a tactical and opera- tional picture of what is happening. Te Marine Corps tends to take a more expeditionary approach to land warfare and relies on smaller, lighter systems—primarily its Joint Tactical COP Workstation (JTCW, where “COP” is an acronym for common operating picture). Tese ruggedized laptops perform a similar function to the larger systems used by the Army, but are smaller and lighter than the full complement of servers deployed by an Army brigade.
Air Force emergency management teams use ordinary Windows- based computers to perform their base defense functions. Navy ships have a customized architecture of command-and-control servers networked with personal computer workstations, and while the ships themselves maneuver through the battlespace, the computer networks onboard are pretty well locked into place— i.e., they are not taken down and later reassembled like those of an Army unit on the move.
Because of these different operational environments and consid- erations faced by the services, each has developed different approaches to how they handle their information and messag- ing needs. JWARN and JEM run on the hardware used by the services for their other command–and-control functions, and that means that JWARN and JEM developers must accommo- date a wide variety of computer architectures. Tose environments range from standard desktop computers used by the Air Force, to command post servers used by the Army, to a cloud-based imple- mentation that can be accessed globally by anyone with a web browser and proper authentication. Tese complex systems pose a particular challenge to developers trying to field products into those environments. Because each service’s architecture must inte- grate multiple programs and resources to field the overall system,
a schedule issue for one component may have cascading effects across the entire system.
MULTIPLES AND MULTIPLES Tat challenge is compounded for joint programs like JWARN and JEM that must integrate with multiple service architectures, while each architecture must itself integrate multiple programs and resources. For example, JWARN and JEM may be required to pass warning information via one method when installed in the Army’s Command Post Computing Environment, but the Marine Corps’ Joint Tactical COP Workstation may use an entirely differ- ent messaging protocol.
With a traditional “single step to full capability” approach to acquisition, that could spell unacceptable program delays. For example, as the Army’s command-and-control system delivery schedule is built, the program management office in charge of that system is building the schedule around a complex series of applications being developed and integrated together. JEM and JWARN are two of those applications, but there are numerous others—many of which are unique to the Army. Meanwhile, the Navy builds its architecture around the integration of a similarly complex series of different applications. Te same goes for the Marine Corps, Air Force and National Guard. Te JWARN and JEM programs might never be able to field their software if they had to wait for a time when all services had “finished” building their computing environments.
‘MAKE THE SOFTWARE MORE USEFUL’ Te first iterations of JEM and JWARN had been developed, but operational users saw new opportunity for what the programs could do. By using a more modern web-based interface, the programs could be adapted to run in a wider variety of environ- ments. Te server that is actually “running” the software could be installed in a place that made sense—in some cases, on a local server at the command post, or perhaps in a cloud-based server that is globally accessible. Te user would simply point a web browser to the appropriate server location. Tis web-based approach was one part of a three-pronged strategy to make the software more useful.
In 2014, the Joint Requirements Office for Chemical, Biological, Radiological, and Nuclear Defense approved the requirements documents for a second version of JWARN and JEM. Tis second version (“JWARN 2” and “JEM 2”) would be where the newer web-based interface could be implemented. Te Joint Require- ments Office, the program offices for each application and the services’ stakeholders also seized the opportunity to take a new
https://asc.ar my.mil 35
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100 |
Page 101 |
Page 102 |
Page 103 |
Page 104 |
Page 105 |
Page 106 |
Page 107 |
Page 108 |
Page 109 |
Page 110 |
Page 111 |
Page 112 |
Page 113 |
Page 114 |
Page 115 |
Page 116 |
Page 117 |
Page 118 |
Page 119 |
Page 120 |
Page 121 |
Page 122 |
Page 123 |
Page 124 |
Page 125 |
Page 126 |
Page 127 |
Page 128 |
Page 129 |
Page 130 |
Page 131 |
Page 132 |
Page 133 |
Page 134 |
Page 135 |
Page 136 |
Page 137 |
Page 138 |
Page 139 |
Page 140 |
Page 141 |
Page 142 |
Page 143 |
Page 144 |
Page 145 |
Page 146 |
Page 147 |
Page 148 |
Page 149 |
Page 150 |
Page 151 |
Page 152 |
Page 153 |
Page 154 |
Page 155 |
Page 156
