Designing naval automation: the "what" not the "how".
Traditionally, naval research and development has been initiated by the Office of Naval Research (ONR) and conducted by such organizations as the Naval Research Laboratory, David Taylor Model Basin (now Carderock Division), and David Taylor Naval Machinery Research Laboratory (also now part of the Carderock Division). However, the boundaries between naval research and development (R & D) and life-cycle engineering are starting to erode, as the Navy looks to increase capability within budgetary constraints. The Navy has reorganized, streamlined, and consolidated many of its research and engineering organizations. In this climate, as an NSWCCD-SSES employee, I became a project manager for a team of NSWCCD-SSES engineers tasked to perform machinery R & D. It was an interesting process, as the team had to first struggle with, then evolve their thinking from, an embedded culture of "modifying what is" to "inventing what isn't."
Reduced Ship's Crew by Virtual Presence
The first project was Reduced Ship's Crew by Virtual Presence (RSVP), sponsored by ONR in fiscal year 1998 to develop a wireless sensor network prototype for Navy ships. Besides NSWCCD-SSES, the team included members from industry and academia. All came with their own backgrounds, mindsets, and views of the world. Each wanted to immediately apply the tool or technology with which he or she was familiar. This presented a challenging dynamic for a project manager who was in charge of getting them--to use a well-worn but appropriate phrase--to think out of the box.
Three Groups, Three Perspectives
The government engineers knew how ships worked today. Their approach was geared toward deckplate wrench turning. They were looking at the existing ship systems and technologies, especially the systems in which they were expert. They wanted to figure out what was on a ship that they could modify to achieve the team's goal. They looked at applying a sensor network to duplicate what is done today. It wasn't immediately apparent that the technology could change the culture--that is, change how ships operate versus automating how they do things currently.
Industry team members wanted to figure out where on a ship to put (with little change as possible) their particular technologies. For a sensor network, this required sensors, radios, networking, and power components. Industry didn't have a working knowledge of the shipboard environment or ship operations.
The team members from university laboratories were interested in validating their current research topics on data acquisition and analysis. They had some level of experience in the ship environment but were not experienced in actually turning their research into a product that could be fielded.
To appropriately leverage the different strengths, the team had to be brought to the same page. The project vision, scope, and end goals had to be agreed upon and--more important--understood in the same way by all team members.
The Integrated Product Team Approach
The first step for RSVP was to adopt the integrated product team format for the team structure. IPTs are cross-functional teams that are formed for the specific purpose of delivering a product to a customer. They are composed of representatives from all appropriate functional disciplines working together to build successful programs, identify and resolve issues, and make sound and timely recommendations to facilitate decision making. IPTs operate under the following broad principles:
* Open discussions with no secrets
* Qualified, empowered team members
* Consistent, success-orientated, proactive participation
* Continuous up-the-line communications
* Reasoned disagreement
* Issues raised and resolved early.
There were many competing ideas for what RSVP was expected to do. Different parties, both inside and outside the team, had different priorities. We had to reach some consensus on exactly what the RSVP system would and would not do. RSVP required a bit more work than most naval R & D projects to establish a technical approach. A specific system, such as a new weapon, has a much more limited set of approaches than a universal sensor system. A bounding of system goals, requirements, and technical approaches had to be performed very early into the program in order to successfully build and test a system by program end.
The RSVP team decided on an approach of a COTS-(commercial off-the-shelf-) based, intra-compartment wireless sensor and local area network (LAN) information distribution and processing system. The installed system would have hundreds of wireless sensor nodes with the capability to acquire hundreds of thousands of sensor data points. The sensor clusters communicate wirelessly with redundant access points within each compartment. The access points would be hard-wired into the ship's LAN and transmit information to workstations located elsewhere in the ship. Once the concept was in place, the RSVP team realized that they knew what they wanted to accomplish, but they still faced the challenge of how to achieve it.
Using Systems-Engineering Methodology
RSVP employed a systems-engineering methodology entitled "integrated product and process development." The IPPD methodology and associated software toolset provided a systems-engineering approach to design and development with an emphasis on affordability. IPPD led the RSVP team through the process of identifying customer requirements; developing and assessing technology alternatives; determining variabilities; performing risk analyses; and estimating performance, producibility, and cost. The IPPD process identified potential customers, major system goals and scope (based on customer inputs), and performance and functional requirements (through subject matter experts and customer representatives).
The next task of RSVP was to generate system requirements. The team went to James Gregory Associates (JGA), Inc., of Columbus, Ohio, to assist in this task. Through a combination of the IPPD methodology, the software-based Process Analysis Toolkit for Affordability (PATA) developed by JGA, and an expert IPPD facilitator, JGA led the RSVP team through the process of requirements generation. The RSVP team was enthusiastic about the way JGA made IPPD work for a diverse team, walking the team through the process of hashing out requirements. RSVP functional and performance requirements were developed during two week-long IPPD sessions.
Before the requirements sessions, everyone had agreed to the general concept; however, it was quickly apparent that each team member brought a different background and set of experiences to the table, which led to different expectations and interpretations of how to achieve the concept. This was an eye-opening realization as we started to go through defining requirements.
The team, at the beginning, just wanted to start building the system. No one realized how different our internal visions would be. It was quite a mental adjustment when JGA brought us all together to define who the customers were. This kicked off a large debate.
The RSVP industry team members considered the customer to be ONR, which was funding the project. ONR considered the customer to be the DD 21 (next generation destroyer, now known as DD(X)) program, which was their transition sponsor. DD 21 considered the customer to be the Blue and Gold competing industry teams, who would build the system. The Navy managers considered the customer to be NAVSEA, which would approve the system and be responsible for its installation and maintenance. The Navy engineers considered the customer to be the sailor who would be the system's end user.
Each of these customers would have different wants and needs, and each of the wants and needs would create its own requirements, which would often be conflicting. The team quickly realized that RSVP could not be all things to all people and that they would have to create a balanced design to focus on a much narrower range of customers.
The team settled on two primary customers: industry and demonstration. The industry customer was defined as the final builders, installers, and maintainers of the system. This customer would require the fully functional RSVP system that would be put on a ship. The RSVP team knew that they did not have the time or resources to build and demonstrate such a system. However, the requirements had to be specified so that we did not create a design that precluded something that eventually could be built.
The demonstration customer was defined as what we would build and demonstrate in the program as a subset of the industry customer. All other customer requirements were wrapped into these two. Requirements were grouped into categories and assigned to the customers: cost, producibility, schedule, system level; and the monitoring areas of environment, structure, machinery, and personnel.
As the categories were put into place, it became evident that each team member had come to the table with a solution in search of a problem. Everyone knew the areas to be monitored and had a favorite sensor or software algorithm to insert in the system. Team members would often make the case for a certain type of monitoring based on the fact that they wanted to use their favorite hardware or software. JGA made us realize this bias through use of the PATA tool and steered us toward thinking of the system as a whole and what the end customer really wanted. This was the first step in the IPT process of team ownership of the problem and, therefore, team ownership of the solution as well. Team members started to view the problem as a whole and keep in mind what they could do to make the others' jobs easier. Achieving this solidarity early on was key to the program's success.
Once customers and categories were defined, the actual requirements themselves were laid down. This sounds easy but in fact, it was the most challenging part of the process. Again, preconceptions got in the way. Often, no great depth of thought was given to monitoring a single parameter because it seemed so basic. Monitoring flooding is a good example. There was great debate on what is considered flooding. It could be any amount of liquid on the deck, an amount only above a certain threshold, or water just in certain spaces. Flooding has structural and stability impacts near the keel of the ship. Much less water has a devastating impact on electronics and machinery systems located in disparate spaces. Fluid in inappropriate places could be triggered by CBRD [Chemical Biological Radiological Defense] washdown, firefighting, regular maintenance, or possibly something as simple as a coffee spill.
JGA was careful not to allow us to think about how we would monitor this. One could not think in terms of hardware at this stage. Existing doctrine had to be our guide, and this required research. The team had to learn what the Navy currently mandates as automated flooding detection and how it is performed. RSVP had to take this a step further and determine exiting watchstanding doctrine (what a sailor is told to watch for that the automation cannot detect and what his reaction should be). We learned that such a level of detail often didn't exist. Sensors were put aboard to provide general indications (a flooding switch tripped), and doctrine was only vaguely defined (walk around and report anything abnormal).
Each requirement had to be assigned ranges and thresholds. This process, on a single parameter, could take hours. There was often outright disagreement over some points; however, the team worked well enough together that it was kept at the level of mutually respectful differences of opinion. The end result of going through the IPPD methodology was that the team agreed to and understood the approach, and understood what was required of the other members to achieve it. It was in this forum that industry learned about ships, academia learned about prototyping and production, and the Navy learned about technical approaches that were not based in existing technology.
Putting the What Before the How
It is often the first impulse of a Navy engineering project team to extrapolate what current technology or a current system should evolve into for the future. That seems like a logical path, given the team's familiarity with current systems. However, from a systems-engineering perspective, it's not the correct approach. There are too many unknowns that could possibly invalidate the solution. From the present day to the Navy after Next, large changes are almost a certainty--the geopolitical environment, warfighting strategies, ship design/operations, and disruptive technologies, to name a few. The correct approach is to establish what the system needs to do and not how it needs to do it.
In concentrating up front on the what and not the how, the entire system scope is captured at a very high level. If that isn't done, there's a very real possibility of missing pieces in the system design, as well as experiencing incompatibilities and competing resource requirements with other integrated systems. There is also the possibility of "scope creep" as more user requirements are identified too far along in the process. All these can result in a system that is potentially far less capable and far too costly to build and maintain.
The author welcomes comments and questions. He can be contacted at firstname.lastname@example.org.
Seman is program manager for ship machinery RDT & E programs at the Naval Surface Warfare Center, Carderock Division in Philadelphia, Pa.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||SYSTEMS ENGINEERING|
|Author:||Seman, Anthony J., III|
|Publication:||Defense AT & L|
|Date:||Mar 1, 2006|
|Previous Article:||Project management and the Law of Unintended Consequences.|
|Next Article:||Attracting and keeping America's young, bright minds.|