Open Architecture Summit 2017 Industry Panel: Getting Everyone On Board Dr. Steven A. Davidson Director, Product Family Development and Open Systems Architecture Raytheon Space and Airborne Systems October 19, 2017 Copyright 2017 Raytheon Company. All rights reserved.
Overview Why OSA is important to all of us Raytheon history with OSA development How Raytheon SAS is implementing OSA and my role Challenges to adoption 11/1/2017 2
OSA Benefits Industry Reuse: Let someone else sweat the details (and spend the money) Interface definitions are a given Messaging protocols and formats have been worked out Test/verification suites available a low/no cost Ability to adopt commercial elements Why make when you can buy? Improved internal system consistency Makes it easier to develop and evolve profitable product families Adds dynamic element to marketplace Potential to unseat incumbents Makes the use of best-of-breed elements easier OSA Enables Rapid Affordable Capability Evolution (ACE) 11/1/2017 3
A Leader in Major OSA Efforts 1998 2006 2008 2009 2010 2013 2015 Software Communications Architecture (SCA) DirecNet High Bandwidth Throughput Government Reference (HBHT GRA) UCS Control Segment (UCS) Future Airborne Capability Environment (FACE) Vehicular Integration for C4ISR/EW Interoperability (VICTORY) Open Mission System (OMS) UAS C2 Standard Initiative (UCI) Common Open Architecture Radar Program Specifications (COARPS) Hardware Open Systems Architecture (HOST) / VITA 84 Sensor Open Systems Architecture (SOSA) Weapon Open Systems Architecture (WOSA) NATO Multi-Domain Control Segment (MDCS) 11/1/2017 4
My Role Responsible for overseeing product platform strategies Develop product family strategies Oversight for product family archicture development Lead product family governance Enhance Raytheon s ability to deliver open architecture-based products to our customers Leverage OSAs to define reuse modules and standard interfaces for product family/platform architecture development Establish and maintain systems and infrastructure (e.g., tools, training) to leverage open standards and architecture Support and promote development of OSAs and standards through direct involvement in their creation, evolution, governance Domain Chief Architect for PFD and OSA Reviews of product Tech Baseline to ensure OSAs and Standards are implemented wherever possible Detailed Architecture Review Boards to evaluate and score how OSAs are implemented and leveraged 11/1/2017 5
CHALLENGES TO ADOPTION (1 OF 3): Terminology What do you mean by open? Our customer community uses the term open in widely different ways Is the architecture open or the design? Adoption of the gray box concept to OSA http://firstmonday.org/article/view/6360/5460 11/1/2017 6
CHALLENGES TO ADOPTION (1 OF 3): Important Terms to Get Right Modular Open Systems Approach (MOSA): DoD's implementation of Open Systems. Within the MOSA context, programs design their system based on adherence to the following five MOSA principles: establish an enabling environment, employ modular design, designate key interfaces, use open standards and certify conformance [OSA Contract Guidebook for Program Managers, v1.1, June 2013] Modular Design: A design where functionality is partitioned into discrete, cohesive, and self-contained units with well-defined interfaces that permit substitution of such units with similar components or products from alternate sources with minimum impact on existing units [Open System Joint Task Force, 2004] Open System Approach: An integrated business and technical strategy that employs modular design and where appropriate, defines key interfaces using widely supported, consensus-based standards that are published and maintained by a recognized standards organization. [OSA Contract Guidebook for Program Managers, v1.1, June 2013] Open System Architecture (OSA): A system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful validation and verification tests to ensure the openness of its key interfaces [OSA Contract Guidebook for Program Managers, v1.1, June 2013] Openness: The procedures or processes used are open to interested parties... are provided meaningful opportunities to participate in standards development on a non-discriminatory basis. The procedures or processes for participating in standards development and for developing the standard are transparent [OMB Circular A-119] 11/1/2017 7
CHALLENGES TO ADOPTION (1 OF 3): Key Takeaways on Open 1. Widely-available, published definitions 2. Consensus-based ( interested parties can shape it) 3. Has a governance process to enables stakeholders to influence and effect the development and evolution 4. Has conformance/compliance validation process Necessary but not sufficient 802.11 Just Because Someone Labels It Open Doesn t Make It So 11/1/2017 8
Interfaces CHALLENGES TO ADOPTION (1 OF 3): The Gray Box Can Speed Adoption Modules Architecture: The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution* Design: The result of transforming requirements into specified characteristics or into the specification of a product process or system** an instantiation of the architecture There can be multiple designs that conform to the same architecture a design is an instantiation of the architecture Gray Box Concept: The functions and behaviors of the modules, and the interfaces, are specified but not how they are instantiated * From ISO/IEC 42010 - IEEE Std 1471-2000 "Systems and software engineering Recommended practice for architectural description of software-intensive systems ** Based on ISO 9000:2005 Plain English Definitions 11/1/2017 9
CHALLENGES TO ADOPTION (2 OF 3): High TRL Requirements As is clear from Title 10 s language, system components must achieve TRL 6 before reaching Milestone B. Although not codified in the U.S.C., TRL 7 or higher is the expected state of technology maturity at Milestone C. In addition, some programs use technology readiness assessments as an integral part of their risk assessment and risk reduction strategy (DoD, 2009). Since production begins after the Milestone C decision, a strong argument can be made that testing and integration should be complete rendering TRL 8 the more appropriate standard. From Improving Acquisition Outcomes Through Simple System Technology Readiness Metrics, Chad L. Dacus, Defense ARJ, October 2012, Vol 4, pp444-461 OR 11/1/2017 10
CHALLENGES TO ADOPTION (3 OF 3): Applicability of OSAs The great thing about standards is that there are so many to choose from Not quite Many OSAs are immature or evolving not ready to be baked into an RFP Each OSA solves a different problem Gaps between what each OSA defines (and its objectives) and what may be needed for a program (no unified agreement on how to address) Each OSA addresses a different space in different ways 11/1/2017 11
Concluding Thoughts Industry does support OSA objectives There are obstacles to adoption that industry can t control It will take time be patient 11/1/2017 12