by CPT John Sipple
Second Battalion, 1st Special Forces Group (Airborne) created a web-based pilot project to use in its forward operating base to streamline the unit�s operations. This project addressed methods to improve time management and staff synchronization, resource management and request tracking, and timely information distribution.
When the battalion commander tasked his S-6 section to develop the FOB webservices project, we were to develop the initial phase internally, then introduce and test it during the FOB�s next deployment, which was as part of the joint/combined Exercise Cobra Gold in Thailand April 29-May 28. This article is a summary of the project and its implementation.
First, I give an overview of the FOB to assist readers who are unfamiliar with Special Operations. I also describe how the battalion operated prior to the webservices project and what the problem areas were. I�ll also explain the project requirements and describe the initial solution. To provide readers some background on the necessary hardware and software, I�ll then briefly address the server-side and client-side platforms and configurations.
Finally, I�ll assess the project and recommend enhancements for future versions. While the outcome of this initial fielding was highly successful, Cobra Gold revealed several areas for continued development. This article summarizes how the project has automated FOB procedures and what can be done to continue improving them.
The FOB is the Special Forces battalion�s headquarters and is composed of five centers that support company (Operational Detachment Bravo) and detachment (Operational Detachment Alpha) operations. The battalion executive officer directs the FOB.
One of the FOB�s centers is the operations center, directed by the battalion S-3. The OPCEN manages mission tracking and planning, sets timelines and issues taskings to the rest of the FOB. The Sensitive Compartmented Information Facility and S-2/intelligence section, weather section, psychological operations, civil affairs and the Air Force controller operate inside the OPCEN. Also from within the OPCEN, the area support team tracks the activities of each deployed unit.
Another center, the support center, provides all logistical and personnel support to the FOB and its subordinate teams. The SUPCEN�s director, the Headquarters Services Company commander, manages the S-1, S-4, service detachment, ammunition section, rigger section, legal section, chaplain, staff surgeon and medical section.
The Signal center plans and operates all command, control, communications, computers and intelligence for the FOB. The SIGCEN � directed by the battalion S-6 � is composed of the S-6 section, multichannel satellite-communications team, Signal detachment and electronic-repair team. The S-6 section is responsible for planning and resourcing missions, including frequency management, equipment and batteries. The multichannel SATCOM team � attached to the SIGCEN from 112th Signal Battalion (Airborne) � provides wide-area network connectivity to the non-secure Internet protocol routed network and secure IP routed network, and telephone access to the Defense Switched Network. The Signal detachment operates high-frequency and single-channel SATCOM base stations, a message center and distribution desk, the tactical local-area network servers and client computers. The electronic-repair section troubleshoots radio and computer-hardware faults.
The fourth center, the base-defense operations center, is responsible for the FOB�s security.
The fifth center, the isolation facility, manages the teams preparing for deployment. While a team is in isolation, its AST works closely with the ISOFAC and the other centers to ensure the team is prepared to execute its mission. Isolation is a critical element in FOB operations; all mission-specific information is compartmentalized to eliminate the possibility of one team compromising another team�s mission.
When a team is in isolation, it submits requests for support to prepare for its upcoming mission. Our battalion�s field standard operating procedure categorizes the requests into the following categories: medical supplies, medical intelligence, aircraft, rigger and air items, communications equipment, communications security, miscellaneous information, batteries, supplies, maps, intelligence and ammunition. The ISOFAC validates the requests and forwards them to the centers for action. One of the FOB�s primary activities is to fulfill RFSs in a complete and timely manner.
Time management. The OPCEN battle captain synchronized the FOB by posting the current timeline in the OPCEN and e-mailing an electronic copy over the TACLAN to all the staff primaries. During the last Joint Readiness Training Center rotation, the FOB improved its procedures by implementing the Microsoft Outlook 2000 Calendar, supported by a Microsoft Exchange 5.5 server. The centers could immediately see a new or changed event just by viewing their Outlook calendar. However, as the FOB adopted Outlook as a staff-synchronization tool, the calendar became cluttered with events and users couldn�t easily correlate events with staff centers, sections, teams, etc. For example, the event �Staff mission brief� didn�t clearly identify that it applies to the ISOFAC, FOB staff planners and ODA assigned to Mission SR002.
RFS procedures. ODAs prepared paper RFSs, and ASTs hand-carried them through the ISOFAC to the appropriate centers. The ODAs, ISOFAC and centers noted the times they received or forwarded the RFS on the form. Eventually, the SIGCEN extended the TACLAN to the isolating units, enabling them to prepare RFSs within Microsoft Word and attach them to an e-mail message. This approach reduced transit time but proved cumbersome and didn�t provide a permanent solution to the RFS process.
Resource management. Each staff section within the centers managed and accounted for its resources independently. For example, the SIGCEN director controlled the stock and distribution of radios without direct oversight. Consequently, the FOB director couldn�t review resource availability without first addressing it through his staff primaries.
At times, information must be distributed quickly throughout the FOB (for
instance, change in Mission-Oriented Protective Posture level, initiation of a
planning cell, notification of a pending attack on the FOB). Before the FOB
webservices project, an operator had to notify every center by calling each one
over DSN or field phone. This consumed precious time.
The SIGCEN�s S-6 section was tasked to address each of the process�s shortcomings by providing an active, web-based synchronization matrix, an improved automated RFS process, a uniform resource-management page and a user-friendly broadcast message application. A �webservices� entity was born in the battalion.
Synchronization matrix. The first objective was to develop a synchronization matrix as described in Field Manual 101-5. We were given the following design specifications:
The matrix must display subordinate units (centers, ODAs, ODBs) vertically on the left column, and times and events horizontally aligned with the respective units. Alternatively, mission identifiers could be shown instead of units.
The matrix must be easily read and should be able to display additional remarks by clicking on the event.
The battle captain should be able to add, modify or delete units, mission identifiers and events through an event-editor function.
The synchronization matrix must appear on each computer and must automatically update itself; the user shouldn�t be expected to refresh the screen manually.
It must be obvious to the user if the matrix has lost its connection by providing some kind of error indication.
The matrix must be available only to the centers and restrict isolating units from seeing each other�s activities.
Finally, the matrix must be embedded in a web browser.
RFS process. The general approach was to automate the RFS process by emulating the structure of an e-commerce site. The desired process is depicted in the following figure.
The RFS system�s design specifications were:
|The automated RFS forms� format and content must correspond to the paper forms found in the battalion�s FSOP.|
|An isolating unit must be able to access the RFS forms through the public-access pages. The RFSs must allow the user to specify quantities and remarks (Step 1, figure above).|
|The webservices section must assign a tracking number to a new RFS automatically based on mission identifier and RFS sequence number.|
|The ISOFAC must validate or cancel the RFS before the webservices section forwards the RFS to the centers (Step 2, figure above).|
|The webservices section must automatically add timestamps to the RFS whenever it�s submitted, validated or completed.|
|The ISOFAC must be able to easily track RFSs in three categories: submitted, in-progress (validated) and completed on a single webpage called the RFS tracking page.|
|Similarly, the centers must be able to track the RFSs specifically for their centers. For example, the ammunition section must be able to set up its page to only view ammunition RFSs. The centers must track their RFSs in two categories � in-progress and completed � via the RFS management webpage (Step 3, above figure).|
|The RFS tracking page and RFS management page must automatically update themselves and must be hidden from the isolating units.|
|When an RFS is completed, it must automatically deduct the number of items from the resource database (Step 4, figure above).|
FOB-wide resource management. The criteria used to design the resource-management webpages were:
|Each section must be able to add, modify or delete items from the resource pages.|
|The resource pages must be categorized according to the FSOP.|
|Item status must be indicated in a �red, amber, green� format, and each section must define the statutes based on quantity thresholds.|
|Each change must be time-stamped automatically.|
FOB alert broadcast. The solution must allow the user to broadcast a message from any computer to all computers. More specifications included:
|The application must load automatically at initial log-on and mustn�t be embedded in a browser.|
|It must be visible as an icon on the screen, and only an administrator can delete or disable it.|
|The application must appear automatically and beep on all computers when a message has arrived. Any user must be able to respond to the message.|
|The application must identify which computer generated the message.|
Public pages. As the name implies, the public pages are available to the entire FOB, including the isolating units. We structured the public pages to be general in nature to avoid breaking the isolation standard. (See following screenshot.)
Following is a list of pages used during the initial implementation at Cobra Gold �02:
|Daily intelligence summaries from the S-2;|
|A library, termed resource pages, containing Special Forces-relevant field manuals and the Joint Electronic Library;|
|A phone directory;|
|The daily weather update;|
|A morale, welfare and recreation page and a chaplain�s page; and|
|An RFS page allowing isolating units to submit requests.|
Restricted pages. The restricted pages contain compartmentalized information pertaining to individual missions and FOB resources. Therefore, access is controlled by means of password authentication.
|SyncMat � The synchronization-matrix application, SyncMat, automatically allows all centers to see a current timeline broken down by subordinate units or missions (following screenshot). Events less than 12 hours long (meetings, backbriefs) are viewable by clicking on the �Day View� tab. Events 12 or more hours in length are viewable by clicking the �14 Day Outlook� tab. By clicking on an event box, a user can see supplemental remarks, which appear in a message box. By default, SyncMat updates itself every three minutes. Events are added, edited or deleted by the battle captain, who accesses the �Event Editor� page. Events can be color coded for easy viewing.|
|Resource pages � The resource pages provide an automated bookkeeping worksheet, allowing users to add, remove and modify resource quantities. Resources and their quantities are retrieved from a Microsoft Access resource database located at the webserver. By depicting the status of resources in the red, amber or green format, the resource pages provide immediate and easy oversight for FOB leadership. One configurable field sets the �green� threshold; resources equal to or greater than the green quantity are assigned a green dot. Another field sets the �amber� threshold; resources quantities less than the green quantity, but equal to or greater than the amber quantity, are assigned an amber dot. All quantities less than the amber quantity are assigned a red dot (figure below).|
|RFS management � The isolating unit selects the appropriate RFS form by clicking on its hyperlink. The RFS form is generated, listing the resources typically available in the FOB. For example, the battery RFS allows the isolating units to enter the desired quantities with optional remarks. (See screenshot below.)|
Once the isolating unit has submitted the RFS, the application provides the ODA a printable receipt, automatically inserts the start time and forwards the RFS to the ISOFAC. The ISOFAC then sees a new RFS automatically pop up under the �Submitted Requests� column on the RFS tracking page. (See screenshot below.) By clicking on its automatically generated identification number, the RFS can be viewed, validated or cancelled. Once the ISOFAC has validated the RFS, it moves to the center column labeled �Requests in Progress� on the RFS tracking page.
After the center has allocated resources for the request, the center director or designated representative completes the RFS, then the RFS moves to the rightmost column labeled �Requests Completed.� After the ISOFAC validates the RFS, it�s accessible to the centers and becomes visible in the RFS management page under the �Active Requests� header. The RFS management page allows each center to select only the RFSs that apply to it and filter out all others. (See screenshot below.)
As with the RFS tracking page, the RFS management page is automatically updated when the status of an RFS changes. The center completes the request, and webservices automatically updates the resource database.
|Alert-message broadcast � FOBAlert! is an application that enables rapid message broadcast to all TACLAN computers. When a user logs in to a computer, FOBAlert! loads automatically and appears as an icon with an exclamation mark on the computer�s desktop. When the user clicks on the icon, a message box opens. After the user types a message and clicks the send button, a message box displaying the message opens on all terminals connected to the TACLAN (screenshot below).|
This section of the article describes system specifications used to support the FOB webservices project during Cobra Gold �02:
|Two Dell Poweredge 2550 servers running Windows NT 4.0�s Service Pack 6a supported the TACLAN. We installed Microsoft Internet Information Server 4.0 on the backup domain controller. By installing the free IIS addition, Option Pack 4, we upgraded the server to run Active Server Pages 3.0. (The dynamic webpages were coded in Visual Basic script and required this configuration to operate.) The SIGCEN configured an open-database-connectivity connection to the Access resource database and shared its parent directory to the SyncMat application. Since we designed the webserver to operate only within the local network, we assigned it an IP address within the private network of 10.1.1.0/24.|
|All client hosts ran Microsoft Windows 2000 Professional, Service Pack 1. We configured all browser start pages to be the FOB webservices homepage. We installed SyncMat and FOBAlert! on each terminal and issued each a private IP address in addition to an externally accessible IP address. We granted certain users write permissions to webpages � for instance, S-2 soldiers had permission to manipulate their INTSUM page, and the weather section could modify the weather page using Microsoft Word.|
The FOB tested the webservices project during Cobra Gold �02 in Lop Buri, Thailand. Here�s a brief synopsis of how each module performed and how it can be improved.
SyncMat. SyncMat performed well; however, it wasn�t used as heavily as we anticipated. This is due, in part, to the fact that the entire FOB was located in a single building, and events changed less frequently than in a JRTC exercise. We modified SyncMat twice, primarily expanding its capacity to display more events. (The original version was limited to 50 events, which proved much too limited.)
Because SyncMat is an ActiveX component, it must be installed on each computer. When introducing a new version, distribution is cumbersome. If developed for the Microsoft .Net platform, we could deploy the new version directly from the server, drastically reducing administrative overhead and delay. A second recommendation is to design SyncMat as a stand-alone Windows application using the entire display surface area. This modification could be used with a screen projector to create a �heads-up picture� on a wall.
RFS management. The FOB used webservices for almost all RFS actions. With only 30 computers installed on the TACLAN, server response was excellent. Unfortunately, due to the dispersed FOB layout, we couldn�t connect some of the isolating ODAs to the TACLAN. Consequently, they were forced to walk to the advance operating base�s building to submit their RFSs. Since the FOB was operating without an ISOFAC, there was some confusion whose responsibility it was to validate RFSs. That task eventually fell to the isolating AOB, forcing the AOB�s soldiers to validate their own RFSs!
Also, the servers crashed during numerous power outages. Even though the servers recovered most of their functionality, the IIS component experienced a critical failure, forcing us to reinstall Option Pack 4. The outage was prolonged because the necessary software wasn�t readily available and had to be downloaded off the Microsoft webpage. Fortunately no data was lost.
A future implementation should include more RFS pages located in the restricted pages specifically for intra-FOB requests. The OPCEN would use this feature, for example, to place a request to the SUPCEN for more toner cartridges. Clearly, such requests shouldn�t be validated by the ISOFAC but should be forwarded directly to the appropriate center.
Resource pages. Before we deployed, we entered all RFS items listed in the FSOP into the resource database. However, before the resource pages are usable, each section must enter initial inventory quantities and determine the green and amber thresholds. Since we introduced most users to the webservices after arriving in Thailand, the resource pages received limited attention. However, where used (batteries, Signal systems and Class VIII), the pages allowed easy oversight and reduced bookkeeping overhead as originally designed. The lesson-learned is to get each staff section to update its initial inventory before deployment.
Public information. Despite its simplicity, the public library pages are an invaluable addition to the webservices and TACLAN. The pages provided immediate access to doctrinal resources and internal documents � such as standard operating procedures or standard reporting formats � to any TACLAN user. The response time clearly outperformed accessing the same resources from external sources.
FOBAlert! The Air Force weather noncommissioned officers broadcast weather advisories successfully on the TACLAN using FOBAlert!. A shortcoming of FOBAlert! is that it currently doesn�t place itself on top of opened applications. If a user is working on a Word document, the message box opens and the computer beeps, but the message box remains hidden under the Word application. This modification can be easily made in an upgraded version.
FOB webservices� initial implementation at Cobra Gold �02 was highly successful; it was among our first effective advances toward a web-based environment used to track time and resources and to distribute timely messages. While it didn�t achieve 100-percent solution yet, it�s clearly an enhancement to FOB�s mission and should continue, focusing on improving its reliability and functionality.
CPT Sipple has been with 1st Special Forces Group (Airborne) at Fort Lewis, Wash., since August 2001. He has served as a battalion Signal officer and is currently the Group Support Company�s Signal detachment commander. In his spare time, he enjoys developing software and is currently working on a second web-based project for the group headquarters.
Back issues on-line | "Most requested" articles | Article search | Subscriptions | Writer's guide
Army Communicator is part of Regimental Division, a division of Office Chief of Signal.