## Slide 1 ![The slide displays a background image of the Earth from space, featuring North America and the Gulf of Mexico. **Top Right:** * 'Raytheon' (in red) * 'SOSA' (large blue letters with a green 'O') * 'Sensor Open Systems Architecture' **Middle Red Banner:** * 'The Sensor Open Systems Architecture' * '(SOSA™) in a Nutshell' **Lower Right Text:** * 'Dr. Steven A. Davidson' * 'Raytheon Space and Airborne Systems' * 'Chair, SOSA Architecture Working Group' * 'October 24, 2018' **Bottom Right Corner:** * 'THE Open GROUP' logo](.sosa-in-a-nutshell/slide-001.jpg) ## Slide 2 ![**Header:** Raytheon Space and Airborne Systems **Title:** The SOSA Approach* **Body Text:** The SOSA Consortium is a C4ISR-focused technical and business collaborative effort... * **Who:** The Air Force, Navy, Army, other government agencies, and industry * **What:** To develop a unified technical Open Systems Architecture standard for radar, EO/IR, SIGINT, EW, and Communications – and the supporting business model * **Why:** To improve sub-system, system, and platform affordability, re-configurability, upgradability, and hardware/software/firmware re-use * **How:** By developing an OSA via modular decomposition (defining functions and behaviors) and associated interfaces (including physical, protocol, and data structure) between the modules **Footer Note:** * Based on abstract of “Sensor Open System Architecture (SOSA) Evolution for Collaborative Standards Development,” SPIE Open Architecture/Open Business Model Net-Centric Systems and Defense Transformation 2017 **Page Number:** 2](.sosa-in-a-nutshell/slide-002.jpg) ## Slide 3 ![**Title:** SOSA Consortium Member Organizations **Logo (Top Right):** Raytheon Space and Airborne Systems **Sponsor Level** * Air Force LCMC * Lockheed Martin * NAVAIR * Raytheon * Rockwell Collins * US Army PEO Aviation **Principal Level** * BAE Systems, Inc. * GE Aviation Systems * General Dynamics * Mission Systems * Harris Corporation * Leonardo DRS * U.S. Army RDECOM * CERDEC I2WD * UTC Aerospace Systems * *(Logo overlay)*: THE Open GROUP **Associate Level** * Abaco, Annapolis Micro Systems, Inc, * Behlman Electronics, Inc., Crossfield Technology, Curtiss-Wright, Delta Information Systems, DRTI, Elma, Gore, Herrick Technology Laboratories, Inc., iRF Solutions, Joint Technical Networking Center, KEYW Corporation, Kontron America, L3 Technologies, Inc., Leidos, Mercury Systems, Meritec, North Atlantic Industries, Inc., Northrop Grumman, OAR Corporation, Pentek, Inc., QubeStation, Inc., Rantec Power Systems, Inc., Real-Time Innovations, Samtec, Selex Galileo Inc, SimVentions, Southwest Research Institute, Spectranetix, Inc., Technology Service Corporation, Telephonics, Tucson Embedded Systems, VTS, Inc.](.sosa-in-a-nutshell/slide-003.jpg) ## Slide 4 ![This slide serves as an agenda or 'Outline' for a presentation. In the top right corner, the logo for 'Raytheon' appears in red, followed by 'Space and Airborne Systems' in black. The main body lists four bullet points: * SOSA Fundamentals * SOSA Consortium * Foundational Methodology * SOSA Consortium Products The page number '4' is located in the bottom right corner.](.sosa-in-a-nutshell/slide-004.jpg) ## Slide 5 ![The slide displays the following text verbatim: Raytheon Space and Airborne Systems SOSA Fundamentals 5](.sosa-in-a-nutshell/slide-005.jpg) ## Slide 6 ![**Header:** Raytheon Space and Airborne Systems **Title:** Architecture vs. Design **Visual Callouts:** Modules Interfaces **Body Text:** * 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 here can be multiple designs that conform to the same architecture **Highlighted Box:** The SOSA Consortium is developing an architecture, not a design **Footnotes:** * 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”' **Page Number:** 6](.sosa-in-a-nutshell/slide-006.jpg) ## Slide 7 ![**Header:** Raytheon Space and Airborne Systems **Title:** What an OSA “Looks Like” **Text Content:** * Modules (can be physical or logical – or a combination): * Activities/functions and behaviors * Physical properties **Diagram Text (Boxes and Labels):** * Module 1 * Key/Defined Interface * Module 2 * External Adapter * External Interface * Module 3 * Module 4 * Module 5 * Module 6 * Module 7 * Environmental Influence **Text Content (Bottom):** * Interfaces: Physical or logical “touch points” * Information exchange, protocols, data content, data format * Mechanical connections **Footer:** 7](.sosa-in-a-nutshell/slide-007.jpg) ## Slide 8 ![**Slide Title:** SOSA Technical Architecture is a Modular Open Systems Architecture **Logo:** Raytheon Space and Airborne Systems **Modular:** - Has encapsulated functionality and behaviors, with well-defined interfaces - Tightly integrated modules, loosely coupled with others **Open:** 1. Widely-available, published definitions ← Necessary but not sufficient 2. Consensus-based (“interested parties” can shape it) and has a governance process to enables stakeholders to influence and effect the development and evolution 3. Has conformance/compliance validation process **Gray Box Concept:** The OSA defines **what** the box does and the interfaces between boxes, but **NOT how** it does it (the IP is inside the box) **Page Number:** 8](.sosa-in-a-nutshell/slide-008.jpg) ## Slide 9 ![**Top Right:** Raytheon Space and Airborne Systems **Title:** Anticipated SOSA Benefits **Content:** * **Faster/more efficient and more cost-effective** * Acquisition — without sacrificing capability * Systems integration * Technology transition * **Improved Lifecycle and supportability** * Tech insertion (new capability) * Commonality and reuse of components * Tech insertion (obsolescence) * **Interoperability** * Between OSA-based systems * Within deployed Product Families **Bottom Right:** 9](.sosa-in-a-nutshell/slide-009.jpg) ## Slide 10 ![**Slide Title:** CV-1 for the SOSA Consortium: Overview **Logo:** Raytheon Space and Airborne Systems **Central Green Block (Vision):** 'Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster **innovation**, industry **engagement**, **competition**, and allow for **rapid fielding** of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements' **Six Pink Blocks (Goals):** 1. **Open:** 'Vendor- and platform-agnostic open modular reference architecture and business model' 2. **Standardized:** 'Software, hardware, and electrical-mechanical module interface standards' 3. **Harmonized:** 'Leverage existing and emerging open standards' 4. **Aligned:** 'Consistent with DoD acquisition policy guidance' 5. **Cost Effective:** 'Affordable C4ISR systems including lifecycle costs' 6. **Adaptable:** 'Rapidly responsive to changing user requirements' **Key (Bottom Right):** * Green Box: Vision * Pink Box: Goals * Grey Box: Capabilities **Page Number:** 10](.sosa-in-a-nutshell/slide-010.jpg) ## Slide 11 ![**Title:** CV-1 for the SOSA Consortium: Part 1 of 6 **Company:** Raytheon Space and Airborne Systems **Green Box (Vision):** Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements **Pink Boxes (Goals):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Grey Box (Capabilities):** a) Development of an open systems reference architecture through a consensus-driven process b) Development of a business model that accounts for government acquisition (e.g., affordability and innovation) and industry interests (e.g., protection of IP and market opportunities) c) Widespread adoption of the above **Key:** Vision Goals Capabilities **Page Number:** 11](.sosa-in-a-nutshell/slide-011.jpg) ## Slide 12 ![**Title/Header:** CV-1 for the SOSA Consortium: Part 2 of 6 (Raytheon Space and Airborne Systems logo) **Top Box (Green - Vision):** 'Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements' **Middle Row Boxes (Pink - Goals):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Bottom Box (Grey - Capabilities):** a) Leverage applicable existing interface definitions and standards b) Creation of new interface standards only when necessary c) Use of a consensus-based process **Key (Legend):** * Green box: Vision * Pink box: Goals * Grey box: Capabilities **Footer:** 12](.sosa-in-a-nutshell/slide-012.jpg) ## Slide 13 ![**Header:** CV-1 for the SOSA Consortium: Part 3 of 6 **Logo:** Raytheon Space and Airborne Systems **Top Box (Green):** Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements **Middle Row (Pink Boxes):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Bottom Box (Grey):** a) Selection of subsets of applicable DoD-oriented open standards b) Selection of subsets of applicable industry/commercial open standards c) Deconfliction and adaptation of incorporated open standards **Key:** * Vision (Green) * Goals (Pink) * Capabilities (Grey) **Footer:** 13](.sosa-in-a-nutshell/slide-013.jpg) ## Slide 14 ![**Header:** CV-1 for the SOSA Consortium: Part 4 of 6 Raytheon Space and Airborne Systems **Top Box (Green):** Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements **Middle Row (Pink Boxes - Left to Right):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Bottom Box (Grey):** a) SOSA Business Guide written to ensure conformance with government documents for R&D, acquisition, and sustainment activities b) Business/acquisition model consistent with sustaining the industrial base (e.g., incentives to invest and engage) **Key:** Key Vision Goals Capabilities **Page Number:** 14](.sosa-in-a-nutshell/slide-014.jpg) ## Slide 15 ![**CV-1 for the SOSA Consortium: Part 5 of 6** **Raytheon Space and Airborne Systems** **Vision (Green Box):** Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements **Goals (Pink Boxes):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Capabilities (Grey Box):** a) SOSA architecture that promotes reuse b) SOSA architecture that enables the use of COTS/GOTS systems c) SOSA architecture that supports upgrading elements without the need for redesign d) SOSA architecture that supports interchangeable parts e) Business Model that incentivizes widespread industry adoption **Key:** * Vision * Goals * Capabilities 15](.sosa-in-a-nutshell/slide-015.jpg) ## Slide 16 ![**Title:** CV-1 for the SOSA Consortium: Part 6 of 6 **Logo:** Raytheon Space and Airborne Systems **Main Box (Green):** Business/acquisition practices and a technical environment for sensors and C4ISR payloads that foster innovation, industry engagement, competition, and allow for rapid fielding of cost-effective capabilities and platform mission reconfiguration while minimizing logistical requirements **Sub-Boxes (Pink):** * **Open:** Vendor- and platform-agnostic open modular reference architecture and business model * **Standardized:** Software, hardware, and electrical-mechanical module interface standards * **Harmonized:** Leverage existing and emerging open standards * **Aligned:** Consistent with DoD acquisition policy guidance * **Cost Effective:** Affordable C4ISR systems including lifecycle costs * **Adaptable:** Rapidly responsive to changing user requirements **Bottom Box (Grey):** a) Fully-modular, scalable open architecture b) SOSA architecture that supports rapid modification of existing SOSA systems c) SOSA architecture that supports ease of multi-INT integration d) Use of plug-and-play technologies **Key:** * Vision * Goals * Capabilities **Footer:** 16](.sosa-in-a-nutshell/slide-016.jpg) ## Slide 17 ![The slide contains the following text: **Raytheon** Space and Airborne Systems **Challenges We Must Address** * Competing interests * Establishing trust relationships * Establishing a business/acquisition strategy that balances the interests (and addresses the concerns) of all stakeholders * Near-term investment and cultural changes needed to realize the long-term benefits of OSA * Conventional planning and acquisition process not optimized for OSA * Traditional contracting models assume requirements can be fully defined up front * COTS standards and products may be ill-suited for many DoD missions 17](.sosa-in-a-nutshell/slide-017.jpg) ## Slide 18 ![The slide features the 'Raytheon' logo in red text in the top right corner, followed by 'Space and Airborne Systems' in black text below it. A thin red horizontal line separates the header from the main body. Centered on the slide is the text 'SOSA Consortium' in large black font. The bottom right corner displays the page number ' 18'.](.sosa-in-a-nutshell/slide-018.jpg) ## Slide 19 ![The slide is titled 'Objective of the SOSA Consortium' with the Raytheon 'Space and Airborne Systems' logo in the top right corner. The body text states: 'Creates a common framework for transitioning sensor systems to an open systems architecture, based on key interfaces and open standards established by industry-government consensus' It lists two specific points: * **Business Architecture:** Acquisition Model and Conformance Program * **Technical Architecture:** Reference Architecture in the form of a Technical Standard The slide number '19' is in the bottom right corner.](.sosa-in-a-nutshell/slide-019.jpg) ## Slide 20 ![The slide is titled 'SOSA Consortium Organization and Makeup' with the logo and text 'Raytheon' and 'Space and Airborne Systems' in the top right corner. **Left Organizational Chart:** * Advisory Board * Steering Committee * Use Case Standing Committee * Architecture WG * Business WG * Hardware WG * Electrical Mechanical WG * Software WG * Data Model SC * System Management SC * Security SC **Right Organizational Charts:** * Government * DoD * Intel * Civilian * Acquisition * Programs * Users * Industry * Defense * Commercial * Large (integrated Systems) * COTS * Medium (Sensors & Subsystems) * Small (Components & Technology) **Footer:** * 20](.sosa-in-a-nutshell/slide-020.jpg) ## Slide 21 ![**Working Group Leadership** **Business** - Chair: John Bowling (AFLCMC) - Vice-chair: Jason Jundt (GE Aviation) **Architecture** - Chair: Steve Davidson (Raytheon) - Vice-chair: Paul Clarke (Northrop Grumman) **Electrical Mechanical** - Chair: Tim Ibrahim (L3 Sonoma EO) - Vice-Chair: George Dalton (KeyW) **Hardware** - Chair: Patrick Collier (Harris Corporation) - Vice-chair: Jason Dirner (U.S. Army RDECOM CERDEC I2WD) **Software** - Chair: Mike Orlovsky (Lockheed Martin) - Vice-chair: Michael Moore (support to U.S. Army RDECOM CERDEC I2WD) Raytheon Space and Airborne Systems 21](.sosa-in-a-nutshell/slide-021.jpg) ## Slide 22 ![The slide displays the following text: * **Header (Top Right):** Raytheon Space and Airborne Systems * **Center:** Foundational Methodology * **Footer (Bottom Right):** 22](.sosa-in-a-nutshell/slide-022.jpg) ## Slide 23 ![**Following an Enterprise Architecture Approach** Raytheon Space and Airborne Systems * **Driven by business needs** * Balancing concerns of the government and industry * **Top-down, fundamentals basis** * Based on agreed-upon drivers grounded in how the Business and Technical Architectures will be used * **Following DoD MOSA guidance** 1. Widely available and published 2. Consensus-based in creation and governance 3. Verification process to ensure correct interpretation of the Technical Standard 23](.sosa-in-a-nutshell/slide-023.jpg) ## Slide 24 ![The slide presents a flowchart titled 'SOSA Process Flow: Color Coded' with the Raytheon Space and Airborne Systems logo. A legend in the top right indicates status colors: Green for 'Sufficiently Complete', Yellow for 'In Progress', and Grey/White for 'Not Started / Immature'. The flowchart contains the following text blocks: * Stakeholders * Consumer-Product Matrix * Target List of Products (in AV-1) * Overarching Objectives (CV-1, CV-2, CV-3) * Use Cases * Business/ Acquisition Model and Other Business Products (e.g., Conformance Plan) * Quality Attributes * Architecture Principles * Common Terminology (AV-2)* * Scope and System Definition (SV-1) * Architecture Pattern(s) * Module (Physical and Logical) Definition * SOSA Interface Definition * Formal SOSA Technical Architecture (multiple Viewpoint Models, starting with SvcV-1) * Common and Dissimilar Functions for Various Sensor Types * Selections from Existing Open and Published Standards and Architectures The page number '24' is visible in the bottom right corner.](.sosa-in-a-nutshell/slide-024.jpg) ## Slide 25 ![**Header:** SOSA Technical Architecture Artifact Roadmap Raytheon Space and Airborne Systems **Legend (Top Right):** Sufficiently Complete In Progress Not Started / Immature **Main Diagram (Flowchart):** * **Use Cases** (Yellow Box) * OV-1 (High Level Operational Concept * OV-2 (Operational Resource Flow) * OV-5b (Operational Activity Model) * **SV-1** (Green Box) * (System Interface Description) * **SvcV-1** (Green Box) * (Services Context Description) * **SvcV-4** (Green Box) * (Services Functionality Description) * **DIV-1** (Green Box) * (Conceptual Data Model) * **Stdv-1** (Yellow Box) * (Standards View) * ongoing * **SV-2** (Yellow Box) * (System Resource Flow Description) * **SV-3** (Grey Box) * (Systems-Systems Matrix) * **SvcV-3a** (Grey Box) * (System-Services Matrix) * **SvcV-2** (White Box) * (Services Resource Flow Description) * **SvcV-3b** (Grey Box) * (Services-Services Matrix) * **SvcV-10a** * SvcV-10b * SvcV-10c (Grey Box) * **SvcV-6** (Yellow/Grey Box) * (Services Resources Flow Matrix) * **DIV-2** (Green Box) * (Logical Data Model) * **DIV-3** (Yellow Box) * (Physical Data Model) **Footer:** Feeds into all * **CV-1 / CV-2** (Green Box) * (Vision, Goals, Enablers) * **AV-1** (Green Box) * (Overview and Summary) * **AV-2** (Green Box) * (Integrated Dictionary) **Page Number:** 25](.sosa-in-a-nutshell/slide-025.jpg) ## Slide 26 ![**Raytheon Space and Airborne Systems** **SOSA Quality Attributes (1 of 2)** **Name:** Interoperability **Description:** The ability of the system to provide data/information to – and accept the same from – other systems, and to use the data/information so exchanged to enable them to operate effectively together. In the context of SOSA, this QA refers to the ability of SOSA-based systems to be able to exchange information during operation, and (possibly with adaptation) be able to interoperate with non-SOSA-based systems **Name:** Securability **Description:** The property of a system such that its design renders it largely protected/inviolable against acts designed to (or which may) impair its effectiveness, and prevents unauthorized persons or systems from having access to data/information contained therein. In the context of SOSA, this QA ensures that the fundamental architecture is one that has minimal attack surfaces and effective authentication enforcement, and SOSA-based systems can be designed so that they can adapt to an evolving threat environment. **Name:** Modularity **Description:** The degree to which a system or element is composed of individually distinct physical and functional units that are loosely coupled with well-defined interface boundaries. In the context of SOSA, this QA enforces the establishment of well-defined, well-understood, standardized system modules that can be created and tested individually for function and conformance. **Name:** Compatibility **Description:** The ability of a system to coexist with other systems without conflict or impairment, or be integrated or used with another system of its type. In the context of SOSA, this QA refers to the ability of SOSA-based systems to be used or integrated with non-SOSA-systems, or with systems designed with earlier versions of the SOSA standard (backwards compatible). **Name:** Portability **Description:** An attribute that describes the reuse of existing hardware or software elements (as opposed to the creation of new) when moving hardware or software elements from one environment (physical or computing) to another. In the context of SOSA, this QA refers to the ability of SOSA-based hardware and software to be used, without modification, in other SOSA-based environments (e.g., different operational domains, different systems, and different sensor modalities), but does not necessarily imply the porting to vastly different physical environments (e.g., operating temperature, shock, vibration – which are design, not architectural, features) 26](.sosa-in-a-nutshell/slide-026.jpg) ## Slide 27 ![**Raytheon** **Space and Airborne Systems** **SOSA Quality Attributes (2 of 2)** Name Description :--- :--- **Plug-and-playability** The capability of a system to recognize that a hardware component has been introduced and subsequently use it without the need for manual device configuration or operator intervention (e.g., USB devices) In the context of SOSA, this QA refers to the ability of a SOSA-based system to recognize the introduction of SOSA-based modules, and through a protocol exchange, to understand and use the capabilities and services that the module offers. **Upgradeability** The ability of a system to be improved, enhanced, or evolved without fundamental physical, logical, or architectural changes. In the context of SOSA, this QA refers to the ability of a SOSA-based system to have specific system, hardware, or software elements replaced with more modern or more capable elements without significant change to the rest of the system **Scalability: Sensor Multiplicity** The capability of a system to cope and perform well under an increased or expanding workload or increased demands, and to function well when there is a change in scope or environment – and still meet the mission needs. In the context of SOSA, this QA refers to the ability of the SOSA architecture to accommodate a multiplicity of sensors, constrained only by design-specific limitations. **Scalability: Platform Size** The capability of a system to cope and perform well under an increased or expanding workload, increased demands, and to function well when there is a change in scope of environment and still meet the mission needs. In the context of SOSA, this QA refers to the ability of the SOSA architecture to be applied to platforms that range from the small (e.g., Class I UAS) to large surveillance aircraft – and possibly even spacecraft **Resiliency** The ability of a system to continue or return to normal operations in the event of some disruption, natural or man-made, inadvertent or deliberate, and to be effective with graceful and detectable degradation of function. In the context of SOSA, this QA refers to the ability of SOSA-based systems to be able to maintain operations while under “duress” caused by physical damage, electronic interference, or cybersecurity attack. 27](.sosa-in-a-nutshell/slide-027.jpg) ## Slide 28 ![**Title:** SOSA Architecture Principle's Names **Logo:** Raytheon Space and Airborne Systems **Business-oriented** 1. The SOSA business and technical architectures is vendor agnostic 2. SOSA Consortium Products are provided royalty-free 3. SOSA Products and Processes Protect the Intellectual Property of Vendors **Technically-oriented** 4. SOSA Standard is Extensible and Evolvable 5. SOSA Architecture Maximally Leverages/Incorporates Existing Industry and Government Standards 6. Resilience (including Cybersecurity) is Enabled by the Architecture 7. SOSA Architecture is Agnostic with Respect to Host Platform 8. SOSA is Agnostic with Respect to Processing Environment 9. Every SOSA Module has Defined Logical Interfaces 10. Every SOSA Hardware Element has Defined Physical Interfaces 11. SOSA Architecture Accommodates Simple through Complicated Systems 12. SOSA Architecture Accommodates Small through Large Systems 13. Modularity is fundamental to SOSA – Physical and Logical 14. Interchangeability is Fundamental to SOSA 15. Reuse is fundamental to SOSA **Boxed Text (Bottom Right):** Each Architecture Principle: * Statement/Description * Rationale * Implications for SOSA **Page Number:** 28](.sosa-in-a-nutshell/slide-028.jpg) ## Slide 29 ![**Header** Architecture Principles: SOSA Example (three of the fifteen shown) Raytheon Space and Airborne Systems **Table 1 (Top)** **Name** #1 The SOS business and technical architectures is vendor agnostic **Statement** The modules and interfaces that make up the SOS technical architecture and standard, and the processes and practices that make up the SOS business/procurement architecture, is equally beneficial to all vendors, offering no inherent advantage or disadvantage to any one company or business sector. **Rationale** The first Goal of SOS is “Open: Vendor- and platform-agnostic open modular reference architecture and business model,” and as such, the SOS business and technical architecture supports a “level playing field” to ensure business fairness, and that the best technical solution, regardless of vendor source, can be incorporated into systems based on the SOS technical architecture. **Implications** The business architecture of SOS ensures that there are no barriers for stakeholder participation in the development or use of the SOS architecture. This includes making material available, eliminating financial barriers (or ensuring that they are minimal). The acquisition model is one that enables all qualified vendors to participate. The technical architecture incorporates standards that favor no particular vendor by specifying standards for which all qualified vendors have equivalent **Table 2 (Bottom Left)** **Name** #14 Interchangeability is Fundamental to SOS **Statement** Modules making up SOS systems are able to be replaced by equivalent modules regardless of the source. Moreover it would be possible to interchange one (entire) SOS system with another SOS system (provided it does not violate physical/environmental requirements). **Rationale** The goals of the SOS effort include openness (platform and vendor-agnostic) and rapid response. The Quality Attributes include plug-and-playability and upgradability. Essential to these objectives is the need to be able to interchange SOS modules to achieve goals, such as using module replacement to upgrade a sensor or modify it because of a changing mission need. This will result in a more robust marketplace where subsystem upgrades become more commonplace as the ease of modular upgrades become apparent. **Implications** Interfaces are very well defined and yet contain a high degree of flexibility. Module-unique interface technologies should be avoided in favor of those that are broadly-applicable. Interface definitions are superset definitions; they include all the functionality/capability that a SOS module or system is anticipated to include. The architecture defines a default behavior for situations where all functions supported in the interface are not implemented. **Table 3 (Bottom Right)** **Name** # 7 SOS Architecture is agnostic with respect to host platform **Statement** The SOS Architecture and Standard applies to a wide range of host platforms (e.g., aircraft, ground vehicle, ship), and makes no assumption regarding the type of vehicle or installation it is resident in or upon **Rationale** Conformance and adherence to this principle engenders hardware and software interoperability and reuse across multiple platforms and multiple mission types. Enabling and maximizing reuse lowers overall development costs and operational costs over the lifetime of any particular program. **Implications** The development of the SOS Technical Standard takes into account a wide range of physical and environmental conditions, and so it specifies, for example, a range of standards-based connector types appropriate for the variety of environments. This may have implications on plug-and-playability, and so it is important that one type of interface (for one environment) easily be adapted (through interface conversion and/or software shim) to another. This enables, for example, a small-vehicle sensor to be leveraged for a large platform.](.sosa-in-a-nutshell/slide-029.jpg) ## Slide 30 ![**Title:** Architecture Approach: Maximize Commonality **Logo:** Raytheon Space and Airborne Systems * Create a (u)superset(/u) reference architecture that can be used for the full range of target sensor systems * – Not all sensors have to incorporate every module (e.g., processing (u)may(/u) be done in a large sensor, or off-board for a small sensor) * Leverage commonality between sensor types as much as the physics will permit * – E.g., image geo-registration for SAR and EO/IR images * – E.g., apertures different and no REX, for EO/IR **Page Number:** 30](.sosa-in-a-nutshell/slide-030.jpg) ## Slide 31 ![The slide displays the following text: * **Top Right:** Raytheon Space and Airborne Systems * **Center:** SOSA Consortium Products * **Bottom Right:** 31](.sosa-in-a-nutshell/slide-031.jpg) ## Slide 32 ![**Header:** Important SOSa Terms to Understand Raytheon Space and Airborne Systems **Left Column:** * **Interface:** The region (physical or logical) where two systems or elements meet and interact * **Sensor:** A device or system that actively or passively detects the physical properties of another entity and produces quantitative data that will be subsequently processed or used (e.g., radar, sonar, IR focal plane, seismometer, etc.) and consist of one or more SOSA Sensor Elements mounted within or on the same platform **Right Column:** * **Hardware Element:** An all-encompassing term for hardware that is incorporated into a SOSA sensor * **Plug-In Card:** Term for any hardware element that is a circuit card that plugs into a backplane * **SOSA Plug-In Card:** Any Plug-in Card that conforms to a SOSA slot profile * **Software Component:** A unit of software that is incorporated into a SOSA sensor * **SOSA Module:** A combination of Hardware Elements and/or Software Components can be instantiated in a way that conforms to the complete definition (functionality, behavior, and interfaces) of the SOSA Modules as defined in the SOSA Technical Standard (SvcV-1 and SvcV-4) **Footer:** 32](.sosa-in-a-nutshell/slide-032.jpg) ## Slide 33 ![This slide, titled **SV-1 (Systems Interface Description*)** with the **Raytheon Space and Airborne Systems** logo, displays two architectural diagrams illustrating sensor configurations. **Top Section (Nominal Case):** * Labeled **Nominal Case**. * An **Electromagnetic Environment** cloud connects to a **Non-SOSA** block and a **SOSA Sensor** group (enclosed in an orange dashed box). * The **SOSA Sensor** group contains four **SOSA Sensor Element** boxes. * These connect to a **Pod (SOSA Host)** and a **Platform (SOSA Host)**. * A **Legend** box lists connection types: **EM Wave**, **Physical Mounting/**, **Cooling**, **Power**, **Analog**, **Digital**, and **Cable Connector**. **Bottom Section (Sensor Pod Case):** * Labeled **Sensor Pod Case**. * An **Electromagnetic Environment** cloud is shown. * A **SOSA Sensor Pod** box contains two **SOSA Sensor Element** boxes. * To its right, a **SOSA Sensor** group (orange dashed box) contains four **SOSA Sensor Element** boxes. * All sensor elements connect to a **Platform (SOSA Host)**. * A **Legend** box repeats the connection key. * A red note box states: **NOTE: Elements and relationships shown are optional; omit unused elements and relationships**. **Footer:** * **\* Several pages of descriptive text omitted here for brevity**](.sosa-in-a-nutshell/slide-033.jpg) ## Slide 34 ![**Header:** Raytheon Space and Airborne Systems **Title:** SOSA Module Definition Process **Content:** * Identified functions performed within radar, EO/IR, SIGINT, EW, and communications systems * Aggregated these functions into logical groups, SOSA Modules, based on the following criteria: 1. Severable (can be separated and used elsewhere) – based on business needs, timing requirements, or other drivers 2. Has minimal complexity interfaces (minimum interdependencies) 3. Can operate as stand-alone or be operated via function/process/system manger (that can operate it as stand-alone) 4. Is independently testable 5. Does not expose IP 6. Facilitates competitive procurement 7. Encapsulates rapid change * For each function within a SOSA Module, we identified – What is required for input (not provided by another function inside that SOSA Module) ,and – What it produced for an output that is used outside the SOSA Module **Footer Box:** The SOSA Technical Standard specifies what the modules do, but not how they do it (IP and innovation are preserved) **Page Number:** 34](.sosa-in-a-nutshell/slide-034.jpg) ## Slide 35 ![**SOSA Modules’ Definition** * **ID Number:** Numerical designator: Major-point-minor * **Name:** Succinct label * **Description:** Paragraph that explains the encapsulated functionality * **Function List:** List of functions contained within the SOSA Module * **Inputs:** List of data items and controls that are ingested by the Module (in certain cases, their sources) * **Outputs:** List of data items that are produced by the SOSA Module (in certain cases, their destinations) **Raytheon** Space and Airborne Systems 35](.sosa-in-a-nutshell/slide-035.jpg) ## Slide 36 ![The SOSA Modules (Textual) Raytheon Space and Airborne Systems SOSA Sensor Management 1.1: System Manager 1.2: Task Manager Transmission/Reception: 2.1: Receive Aperture/ Transducer/ Camera 2.2: Transmit Aperture/ Transducer/ Laser 2.3: Conditioner-Receiver-Exciter Process Signals/Targets 3.1: Signal/Object Detector and Extractor 3.2: Signal/Object Characterizer 3.3: Image Pre-Processor 3.4: Tracker Analyze/Exploit 4.1: External Data Ingestor 4.2: Encoded Data Extractor 4.3: Situation Assessor 4.4: Impact Assessor and Responder 4.6: Storage/Retrieval Manager Convey 5.1: Reporting Services Support System Operation 6.1: Security Services 6.2: Encryptor/Decryptor 6.3: Guard/Cross-Domain Service 6.4: Network Subsystem 6.5: Calibration Service 6.6: Nav. Data Service 6.7: Time & Frequency Service 6.8: Compressor/ Decompressor 6.9: Host Platform Interface 6.10: Power 36](.sosa-in-a-nutshell/slide-036.jpg) ## Slide 37 ![**Header:** Raytheon Space and Airborne Systems The SOSA Modules (Graphical part of SvcV-1) **Diagram Modules (Top to Bottom, Left to Right):** * 1.1: System Manager * 1.2: Task Manager * 2.1: Receive Aperture/Transducer/Camera * 2.2: Transmit Aperture/Transducer/La ser * 2.3: Conditioner-Receiver-Exciter * 3.1: Signal/Object Detector and Extractor * 3.4: Tracker * 3.3: Image Pre-Processor * 3.2: Signal/Object Characterizer * 4.1: External Data Ingestor * 4.2: Encoded Data Extractor * 4.3: Situation Assessor * 4.4: Impact Assessor and Responder * 4.6: Storage/Retrieval Manager * 5.1: Reporting Services * 6.1: Security Services * 6.2: Encryptor/Decryptor * 6.3: Guard/Cross-Domain Service * 6.10: Power * 6.4: Network Subsystem * 6.5: Calibration Service * 6.6: Nav. Data Service * 6.7: Time & Freq'cy Service * 6.8: Compress / Decomp'ss * 6.9: Host Platform Interface **Footer:** 37](.sosa-in-a-nutshell/slide-037.jpg) ## Slide 38 ![**Slide Title:** Documenting the SOSA Modules **Header:** Raytheon Space and Airborne Systems **Left Section: Extract from the SvcV-1** This section lists modules 2.3, 3.1, 3.2, 3.3, 3.4, 4.1, and 4.2 with their descriptions. * **2.3 Conditioner-Receiver-Exciter:** The Conditioner-Receiver-Exciter may perform receive functions, transmit functions, or both. The receive side may include space-time adaptive processing (STAP), low-noise amplification (with gain control), amplitude limiting, band-pass filtering, frequency translation, application of calibration corrections, channelization, image formation, tagging with metadata, RF signal distribution, data framing, and datacube formation (for hyperspectral). The transmit side may include amplification (with gain control), amplitude limiting, frequency translation, waveform conversion (analog to digital, digital to analog), waveform generation, RF signal distribution, calibration, and adaptation to spectrum use. * **3.1 Signal/Object Detector and Extractor:** The Signal/Target Detector and Extractor is responsible for detecting electromagnetic signals or physical objects among the noise and other signals and objects in the environment (e.g., clutter or interference). This module extracts a detected signal, detected object, or image chip for downstream processing. Techniques to perform this may include clutter suppression and extraction of scintillation/decorrelation information, interference suppression, the use of constant false alarm rate techniques, coherent and non-coherent integration, image enhancement (including edge detection and sharpening), and employment of gating logic to manage and balance search volume returns with existing object tracks. * **3.2 Signal/Object Characterizer:** The Signal/Object Characterizer is designed to make measurements on images, signals and physical objects to determine attributes, properties, categories, classes, types, or identification — all with confidence estimates. * **3.3 Image Pre-Processor:** The Image Pre-Processor module prepares the image for final use and processing. For SAR, this module forms images from sensed RF data. This module also registers images to maps and other images. * **3.4 Tracker:** The Tracker Module correlates detections and tracks over time, forming new or updated tracks. It is responsible for all track management functions and producing track reports. The core functionality of the Tracker is data association, track initiation, track drop, track update, state and covariance estimation, and split track handling. Estimation of relative position or location (geolocation), when feasible, is also included in this function. * **4.1 External Data Ingestor:** The External Data Ingestor is responsible for ingesting data from other SOSA sensors, as well as sensors that don't conform to the SOSA Technical Standard (converting from non-Conformant format to Conformant format as needed), and distributes ingested data to other SOSA modules. * **4.2 Encoded Data Extractor:** The Encoded Data Extractor is applicable to SIGINT, communications, and EW. It is responsible for demodulating and extracting message content (communications and EW), extracting internals (SIGINT and EW) and human language processing (SIGINT). **Right Section: Extract from the SvcV-4** This section is a table with columns: Module, Mode, Functions (and Prior Modules), Input (See Table 3 for Definition), Output (See Table 3 for Definition). * **6.5 Calibration Service (Mode: ALL):** * **Functions:** Intake the injected test signal; Collect output of either cal test points or main; Disable modules not under test; Note: Do not preclude the design option to have the data source and processing be internal to the sensor (not needing external injection). * **Input:** Injected test signal = RF Signal, or Image/Video Stream, or Demodulated Signal; Calibration Command; Safety Interlock * **Output:** Electromagnetic Source Command; Calibration Result(s) * **6.6 Nav Data Service (Mode: ALL):** * **Functions:** Ingest platform/sensor location and orientation (if available); Blend internal and external spatial data (if available); Distribute platform/sensor location and orientation * **Input:** Navigation Data (external source – option, since could be internally generated); Settings * **Output:** Navigation Data * **6.7 Time & Frequency Service (Mode: ALL):** * **Functions:** Ingest time from external source (if available); Blend internal and external time data; Generate time internally (design-dependent); Provide time to internal function (as a timing signal/clock or time message); Provide local oscillator/frequency reference * **Input:** Time Reference (external source) * **Output:** Time Reference; Frequency Reference * **6.8 Compressor/Decompressor (Mode: ALL):** * **Functions:** Compression; Decompression; Codec functions (non-specific * **Input:** Compression Command; Compressed Data; Compression Metadata; Decompression Command; Decompressed Data; Decompression Metadata * **Output:** Compressed Data; Compression Metadata; Decompressed Data; Decompression Metadata **Footer:** 12/13/2018 38](.sosa-in-a-nutshell/slide-038.jpg) ## Slide 39 ![**Header:** Module-to-Module Interfaces: Top-Down Approach **Logo:** Raytheon Space and Airborne Systems **Text Content:** * **Data Model defines the information content flowing between SOSA Modules** * DIV-1 Conceptual Data Model * Overall data scheme * DIV-2 Logical Data Model * What is contained in data elements * DIV-3 Physical Data Model * How data elements are represented * **Interaction Categories define how the data is exchanged** * E.g., Pub-Sub, Request-Response, etc. * **Messages define how those data items are conveyed** **Diagram (Labeled 'A Portion of the SOSA DIV-1'):** * **Top Entities:** 'Management Data' (Describes) 'Managed Entity'. * **Managed Entity Branch:** Connects to 'Sensor' and 'Module'. * **Management Data Branch:** Connects to 'Discovery Information', 'Configuration Description', 'Control State', 'Health', 'Security Parameters', 'Capability', 'Task', and 'Assignment'. * **Blue Annotation:** 'These are specialized for each managed entity' points to the Management Data branch. * **Control State Branch:** Connects to 'Mode' and 'State'. * **Health Branch:** Connects to 'Status' and 'Fault'. * **Capability Branch:** 'Requires' 'Resource'. * **Task Branch:** 'Uses and Releases' 'Availability'.](.sosa-in-a-nutshell/slide-039.jpg) ## Slide 40 ![**Header:** Interaction Categories and Data Purpose Raytheon Space and Airborne Systems **Left Column:** * Analog signal (e.g., RF, DC voltage) * Request-Response * Publish-Subscribe * Bulk transfer (e.g., digital stream) * Event Notification * Secure Request-Response **Right Column:** * Mission Data * – Related to the purpose of the system (e.g., sensing, PED, communications) * Management Data * – Related to control of the system **Bottom Box:** The differentiation of Mission Data and Management Data are reflected in the DIV-1 Conceptual Data Model **Page Number:** 40](.sosa-in-a-nutshell/slide-040.jpg) ## Slide 41 ![**Title:** Candidate Software Runtime Environment Interface Based on the FACE™ Technical Architecture **Logo:** Raytheon Space and Airborne Systems **Diagram Content (labeled 'FACE Boundary'):** * **Top Segment:** 'Portable Components Segment' containing 'Fusion', 'Own Ship Position', 'Fuel Service', 'FACE Component'. * **Right Segment:** 'Transport Services Segment' containing 'Sockets Transport', 'Transport Service Capability', 'Type Abstraction Capability', 'Distribution Capability', 'Configuration Capability'. * **Middle Segment:** 'Platform-Specific Services Segment' containing: * 'Platform-Specific Device Services' (with sub-items 'GPS', 'EGI', 'OFP Device') * 'Platform-Specific Common Services' (with sub-item 'System-Level Health Monitoring') * 'Platform-Specific Graphics Services' (with sub-item 'Graphics Service') * **Lower Segment:** 'I/O Services Segment' containing 'Service', 'MIL-STD-1553 Service'. * **Left Column:** 'Operating System Segment', 'Operating System', 'Language Run-time', 'Component Framework', 'Health Monitoring'. * **Bottom Layer:** 'Device Driver', 'Device Driver', 'Graphics Driver'. * **Interface Hardware:** 'Interface Hardware (e.g., MIL-STD-1553, Ethernet)'. * **External Connections:** 'OFP Device', 'GPS', 'Platform Displays', 'EGI'. * **Key:** 'FACE Defined Interface', 'External Interface'. **Text Block:** 'SOSA Software Runtime Environment Interface (REI) may consist of SOSA application software interface to host system for language run time and calls to operating system services as defined by FACE OSS interface, SOSA platform specific software and low level I/O as defined by FACE PSSS and IOSS, SOSA operating system as defined by FACE (Posix, ARINC 653, C, C++, Java, and Ada)' **Page Number:** 41](.sosa-in-a-nutshell/slide-041.jpg) ## Slide 42 ![**Title/Header:** Hardware Approach: “Box Level” Specification Raytheon Space and Airborne Systems **Main Content:** * Applicable to a variety of sensor/avionics platforms * Hardware Module defined here is an individual card that fits into the box). * The system is inherently interoperable, compatible with non-Conformant hardware via a set of standard bridge interfaces that are * Plug-and-playable * Upgradeable (evolvable) * Securable * Compatibility/alignment with * VITA standards * HOST * CMOSS **Diagram Labels (Left/Center):** * Payload input * Processing card * Switch card * Memory card * Output card * Power card * Utility Plane * SE P0 * Key * User Defined * Data plane - 6 Fat Pipes * Control Plane - 6 Ultra-Thin Pipes * SE P1/J1 * Data Plane - 2 Fat Pipes * SE P2/J2 * SE P0/J0 * Unused (SWD) * Maintenance Plane * Reserved Utility Plane * RT Data Plane - 1 FP * CTRL Data Plane - 1 UP * Control Plane - 1 UP * Expansion Plane - 3 FPs * 67.3 Module C * VITA 67.3 Module C (Class = optional) **Diagram Labels (Right):** * Payload slots * Switch slots * Payload slots * VPX 1 * VPX 2 * VPX 3 * VPX 4 * VPX 5 * VPX 6 * VPX 7 * VPX 8 * VPX 9 * VPX 10 * VPX 11 * VPX 12 * Slot numbers are logical, physical slot numbers may be different * Data Plane (FP, TP) * Control Plane (UTP) * Management Plane (PMB) * Utility Plane Includes Power * Data Plane * Switch * 42](.sosa-in-a-nutshell/slide-042.jpg) ## Slide 43 ![**Header** SOSA Hardware Module Development (Samples) Raytheon Space and Airborne Systems **Diagram 1: Control/Expansion Plane Switch** * **Left Labels:** Utility Plane, Reserved, Maint. Port, Reserved, Utility Plane, Control Plane — 1 Thin Pipe * **Internal Blocks (Top to Bottom):** SE P0/J0, S E, Diff, P1/J1, S P2/J2 E * **Right Labels:** Key, Data Plane — 6 Fat Pipes, Control Plane — 8 Ultra-Thin Pipes, Key **Diagram 2: I/O Intensive SBC** * **Left Labels:** Utility Plane, USB 3 power, Maint. Port, Reserved, Utility Plane, Serial ports, USB 2 power, 3 of GPIO * **Internal Blocks (Top to Bottom):** SE P0/J0, S E, Diff, P1/J1, S, Diff, P2/J2 * **Right Labels:** Key, Data Plane — 1 FP, Expansion Plane — 1 FP, P1w9-X12d XMC map, Control Plane — 2 UTPs, Video — 1 TUTP, 1 of USB 3 and 1 of USB 2 — 1 TP, Storage — 1 UTP, Control Plane — 1 TPS, X16s XMC map, X8d XMC map, Key **Diagram 3: 6U Red/Black Switch** * **Left Labels:** Utility Plane, Maint. Port, Reserved, Utility Plane, 1000 BASE-T, 1000 BASE-T, Reserved, 100 Base-T, Reserved, Maint. Port * **Internal Blocks (Top to Bottom):** SE P0/J0, S E, Diff, P1, P2/J2, Diff, P3/J3, S E, P4/J4, S E, Diff, P5/J5, S E, J5, Diff, P6A/J6A, P6B/J6B * **Right Labels:** Key, Data Plane — 8 Fat Pipes, Key, Data Plane — 6 Fat Pipes, Data Plane — 16 UTPs, Ground, Control Plane — 15 UTPs, VITA 65 Aperture Pattern J for optical/coax, Key **Footer** 43](.sosa-in-a-nutshell/slide-043.jpg) ## Slide 44 ![**Header:** Raytheon Space and Airborne Systems **Title:** SOSA (Draft) Technical Standard **Left Column (Document Cover Image):** * An Open Group Standard * Technical Standard for Sensor Open Systems Architecture (SOSA™) Reference Architecture * SOSA Sensor Open Systems Architecture * THE Open GROUP * You have a choice: you can either create your own future, or you can become the victim of a future that someone else creates for you. By seizing the transformation opportunities, you are seizing the opportunity to create your own future. * -VADM Arthur Cebrowski **Right Column (Bullet Points):** * Documents the SOSA Reference Architecture * Contains normative and non-normative content * Major Sections * Architecture Overview * Architecture Definition * SPSA Technical Standard * Appendices * StdV-1 (Applicable Standards) * AV-2 (Integrated Dictionary) * Use Cases * DIV-2 (Logical Data Model) and Data Dictionary * Host Platform / Sensor Connector Details * Slot Profiles * Backplane Examples **Footer:** http://opengroup.org/sosa 44](.sosa-in-a-nutshell/slide-044.jpg) ## Slide 45 ![**Slide Title & Header:** SOSA Business Guide Raytheon Space and Airborne Systems **List of Topics:** * Open Systems Architecture principles * Business Model * Value proposition for C4ISR open systems architecture * Overview of the SOSA Technical Standard * Examples of how the acquisition process is affected by OSA * Guidance for writing solicitations that include SOSA requirements * Examples of contracting language relevant to the inclusion of OSA **Left Image (Document Cover):** * Open Group Guide * SOSA™ Business Guide Version 0.8 * SOSA Sensor Open Systems Architecture * THE Open GROUP * NOTICE: 'Version 0.9 of the SOSA™ Business Guide is a draft document intended to make public the current state and direction of development of the business aspects of the SOSA approach. We invite your feedback and guidance so as soon as possible for your comments to be considered for the next version of this publication. To provide feedback please send comments by email to ososa-admin@opengroup.us. This Guide is valid through April 30, 2018 only. For information on joining The Open Group SOSA™ Consortium, please send email to ososa-admin@opengroup.us or visit our website at www.opengroup.org.sosa.' **Diagram (Bottom Right):** * **Entities:** Procuring Organization, Performing Organization, Stakeholder Community * **Interactions:** OSA Requirements, Conformant System, OSA SMEs, OSA Tasks * **Stakeholder Community Details:** Transparency & Oversight, Procurer, Performer, Third Party * **Standards/Processes:** The SOSA Technical Standard, Conformance Verification, Candidates for The SOSA Technical Standard * **Bottom Row (Yellow Boxes):** Business Guide, Contract Guide, Technical Standard, Conformance Program **Footer:** 45](.sosa-in-a-nutshell/slide-045.jpg) ## Slide 46 ![**Raytheon** **Space and Airborne Systems** **Key Take-Aways** * The SOSA Consortium is developing a unified modular, open reference architecture – and associated business model – for radar, EO/IR, SIGINT, EW, and communications * Following MOSA principles, gray box model to protect IP and encourage innovation * Structured, top-down approach: Quality Attributes, Architecture Principles, using DoDAF * Using a consensus-body approach to balance interests of all parties * Five Working Groups: Architecture, Business, Electrical/Mechanical, Hardware, and Software * Products include the SOSA Technical Standard and the Business Guide * Initial “Snapshots” have been released for both 46](.sosa-in-a-nutshell/slide-046.jpg) ## Slide 47 ![**Header:** Raytheon Space and Airborne Systems How to Reach Us and Learn More **Website Screenshot Content:** * **URL:** http://opengroup.org/sosa * **Logos:** SOSA Sensor Open Systems Architecture THE Open GROUP * **Navigation Links:** Help Member Login * **Banner Left:** Sensor Integration Simplified™ * **Banner Right (Blue Box):** The Open Group SOSA™ Consortium enables government and industry to collaboratively develop open standards and best practices to enable, enhance and accelerate the deployment of affordable, capable, interoperable sensor systems. * **Left Sidebar Menu:** * SOSA (Sensor Open Systems Architecture) * Press Release * SOSA Frequently Asked Questions * SOSA 2017-2018 Elected Officers * SOSA Members * What is the SOSA™ Consortium? * SOSA™ Vision * SOSA™ Events * Join The SOSA™ Consortium * **Center Content Blocks:** * About SOSA™ Consortium (Image of jets) -) What is the SOSA™ Consortium? * Vision (Image of Earth) -) Vision * Events (Image of people) -) Events * Join SOSA™ Consortium (Image of people) -) Join the SOSA™ Consortium * **Right Sidebar Links:** * ) Trademark Usage/Copyright * ) Press Coverage * ) Organizational Structure * ) SOSA Business Guide * ) SOSA Technical Standard * ) SOSA Terms & Conditions * ) Members * ) SOSA Officers * Members' Actionable Reminders * **Footer:** Privacy Legal The Open Group Website © The Open Group 1995-2018 **Contact Information Box (Bottom Right):** Dr. Steven A. Davidson Director, Product Family Development and Open Systems Architecture Raytheon Space and Airborne Systems steve_davidson@raytheon.com 508-361-2827 **Footer:** 47 /2018](.sosa-in-a-nutshell/slide-047.jpg) [🔗 Link to the original document](.sosa-in-a-nutshell/sosa-in-a-nutshell.pdf)