0840-0910 Dr. Pam Savage-Knepshield ARL-HRED Supporting ...

3. NAVSEA Commonality Drivers Chief of Naval Operations Guidance for 2007-2008 Tasking: �Using Open Architecture as an enabler, reduce Surface Ship Combat systems baselines from 16 to eight in the next ten years.� Department of the Navy Objectives for FY08 and Beyond: �Implement Naval Open Architecture across Navy and Marine Corps combat systems� PEO Integrated Warfare Systems (IWS) Common Display System (CDS): Small family of consoles for use on multiple platforms on Navy surface ships, submarines, and aircraft Three-screen horizontal variant currently being designed Common Processor System (CPS) also in development Audio: what is behind these drivers? COSTAudio: what is behind these drivers? COST

4. Current Surface Ship Combat Systems

5. Surface Navy Common Architecture Strategy

6. NAVSEA Display Challenge Major issues for Modernization: Wider and shorter displays, with higher resolution Integration of communications panel and peripheral devices into main displays Potential replacement of physical buttons with touch screen interface

7. Example: SEA 05H Common Presentation Layer NAVSEA Standard 03-01, "Common Presentation Layer (CPL) Guide," dated September 2006 Level of detail comparable to style guide Based on many existing Navy and industry standards Sections with detailed implementation guidance completed Sept 2007 Hull, Mechanical, and Electrical (HM&E) Interfaces Tactical Situation (TACSIT) Interfaces CPL applications include: Style Guide update for DDG 1000 Style Guide update for LCS Style Guide basis for DDG Modernization Universal Control Console User interface for Periscope Detection Radar POC: Robert Fagan, NAVSEA 05H, 202-781-3319POC: Robert Fagan, NAVSEA 05H, 202-781-3319

8. Example: PEO IWS Open Architecture Display Components Software components developed by PEO IWS and NSWC Dahlgren for reuse across systems with tactical displays Functionality selected based on: Improved performance Commonality across systems Potential for decreased training, maintenance or upgrade time Components developed: Common Track Filter: current filter controls do not support full range of symbology options Pop-Up Declutter Tool: provides for information and selection from tightly packed group of track symbols Software components and supporting information submitted to SHARE (Software Hardware Asset Reuse for the Enterprise) repository POCs: Joe Herbert, PEO IWS 7, 202-756-3871; Karole Davidson, NSWCDD W62, 540-653-1241POCs: Joe Herbert, PEO IWS 7, 202-756-3871; Karole Davidson, NSWCDD W62, 540-653-1241

9. PEO IWS OA Display Components

11. Example: Air Control Commonality Different user interfaces for shipboard air controllers in different combat systems Required multiple simulators, training pipelines, and NECs User interface terminology not fully consistent with radio communication standards Substantial subset of functionality out-of-date New control menus developed, compatible with standardized terminology Common across combat systems Common across fixed-wing (AIC) and rotary-wing (ASTAC) controllers Benefits: User interface consistent with training procedures and voice communications Consolidated training materials and pipelines Increased options for personnel assignment Improved performance Keys to Success: Active, multi-organizational working group Involvement of operational and training communities Baseline schedule permits implementation of updates POC: Ken Pierson, CSCS, 540-653-2724POC: Ken Pierson, CSCS, 540-653-2724

12. Example: Naval Nuclear Propulsion Program HFE IPT recently initiated for Naval Nuclear Propulsion Program (NNPP) Collaboration between SEA 08 (NNPP), SEA 05Z (HM&E), and SEA 05H (HSI) Goal is to refine a single style guide and common user interface based upon SEA 05H Common Presentation Layer: NNPP components Hull, Mechanical, and Electrical (HM&E) systems (steam and nuclear) Issues of interest: Suitable for new construction or forward fit and for modernization or backfit Leverage transfer of training from existing systems where it makes sense Compatibility with �cultural norms� and expectations of participating communities Account for personnel differences, including color vision requirements Accommodate different lighting environments POC: Daniel Wallace, NSWCDD W62, 540-653-8097 POC: Daniel Wallace, NSWCDD W62, 540-653-8097

13. Success Factors for Display Commonality Clearly establish scope Select the components or programs that can be impacted Specify areas for commonality Information sources, formatting, terminology, controls � Specify perspective for commonality Address end-user perspective, not only developer perspective Obtain common funding for common solutions Constrained funding leads to partial solutions Differentiate from or eliminate competitors Keep the grass from being greener on the other side Quantify the benefits Performance improvements should tie to mission performance Cost ROI needs to bear fruit in 1-3 years Tackle high payoff items and get quick, powerful wins

14. Benefits of Display Commonality Benefits exist across HSI domains: Human factors engineering Increased interface consistency reduces probability of error Better efficiency and effectiveness, if best among options is selected Manpower Facilitates workload reduction, enabling concurrent oversight of multiple functions, possibly leading to reduced manpower Personnel Personnel codes can cover broader range of systems or roles Increased flexibility in personnel assignments Training Consolidation of training courses and materials Increased transfer of training and shorter training pipelines Subsequent training can focus on proficiency End-user Greater flexibility in watchstation assignments Potential increase in Ao with common troubleshooting capability Development and maintenance of software Code reuse and modular designs Quicker, easier upgrades Manpower: aggregate workload permittingManpower: aggregate workload permitting

15. Expected Commonality Benefits Across Perspectives

16. Commonality Perspectives (1 of 3) Within a component or system User fully expects commonality Most straightforward when within lifelines of a single program Individual system may still have multiple developers May have different software components accessed via same hardware device or vice versa When it is missing: Difficult and time-consuming training Substantial user performance impacts Within a task May cross components or systems User likely to expect commonality When it is missing: Large impact expected on cognitive workload, task delays, and error rates Increased training burden, increased training coordination

17. Commonality Perspectives (2 of 3) Within a role or job User unlikely to be surprised by differences Different systems expected to lack full commonality When it is missing: Increased error rates for critical differences Inefficiencies in execution May increase amount of training or cause negative transfer Across a team User expectation will vary When it is missing: Increased communications difficulty Reduced common awareness Reduced opportunity for cross-training or training transfer across roles in a team

18. Commonality Perspectives (3 of 3) Within a billet Individuals typically have multiple roles, multiple missions or modes (e.g., combat operations and damage control) When it is missing: Lost opportunity for transfer of training Possible increase in error probability Across platforms Comparable functions with different systems When it is missing: Multiple training pipelines Reduced flexibility in personnel assignments Along a career or within a community or specialty Opportunity to use prior training as basis for increased proficiency When it is missing: More resources, longer trainee time required between assignments Low transfer of training requires training focus on basics rather than expertise

19. Expected Commonality Benefits Across Perspectives