# Reference Architectures Having explored the hierarchy of digital systems from the signals up to the mechanical form factors, it is clear that all those building blocks are strictly application-agnostic. The way we combine FPGAs, System-on-chip, memories, boards, mezzanines, and units is largely independent of what the target application is. For this reason, industries tend to gather around and agree on baseline architectures and coordinate things like signal routings, data rates, and protocols. These are called open reference architecture and aim to streamline the design process for specific applications such as radar, avionics, or electronic warfare. Examples of open reference architectures are: - SAVOIR: The Space Avionics Open Interface Architecture (SAVOIR) is an initiative primarily driven by the European Space Agency (ESA) to standardize the interfaces and architectures in space avionics. SAVOIR aims to address several key goals: - Modularity and Interoperability: By standardizing interfaces, SAVOIR facilitates the development of modular and interoperable systems. This means components from different manufacturers can work together seamlessly, allowing for more flexible and cost-effective spacecraft designs. - Reduced Development Time and Cost: Standardized interfaces and architectures help in reducing the time and cost associated with developing spacecraft avionics. It simplifies the integration process and allows for the reuse of components across different missions. - Enhanced Reliability and Performance: With a standard architecture, the reliability of space avionics systems can be improved as components and systems are more thoroughly tested and understood. It also promotes the use of best practices in design and implementation. - Collaboration and Innovation: By creating a common framework, SAVOIR encourages collaboration among various stakeholders in the space industry, including agencies, companies, and academic institutions. This collaborative environment fosters innovation and helps in the development of more advanced avionics systems. - ADHA: The Advanced Data Handling Architecture (ADHA) is a conceptual framework developed by the European Space Agency (ESA) aimed at modernizing and standardizing the data handling systems used in space missions. ADHA addresses these needs by providing a unified approach to data handling across various missions, spacecraft, and ground systems. ADHA's primary objectives include optimizing the way data is collected, processed, and transmitted to improve overall mission efficiency, and establishing common standards and protocols for data handling to ensure compatibility and interoperability between different systems and components. - SOSA: SOSA is a collaborative effort led by the U.S. Department of Defense, along with industry and academia partners, to create a common architecture for radar, electronic warfare, and signals intelligence (SIGINT) systems. Its main goal is to facilitate interoperable and modular systems, which can be easily upgraded and adapted. By using a common architecture, different components from various manufacturers can work together seamlessly. SOSA focuses on creating a set of standards for hardware, software, and mechanical components to ensure they are interoperable and interchangeable. ## SAVOIR > [!attention] > Section in #development  > [!Figure] > _SAVOIR avionics functional reference architecture. Credit: ESA_ ## Advanced Data Handling Architecture (ADHA) To contribute towards the European Space Agency's (ESA) objectives of reducing spacecraft development time, achieving cost efficiency, and promoting faster adoption of innovative technologies, the On-Board Computer and Data Handling Systems section (TEC-EDD) is currently engaged in several activities with European industry partners, having the aim to develop across ESA member states an Advanced Data Handling Architecture (ADHA) based on standardized, interchangeable, and inter-operable electronics modules equipped with the latest generation of microelectronics components. The main goal of ADHA is to develop products primarily designed for utilization in Low Earth Orbit (LEO) satellites, particularly for Earth Observation missions. ADHA is all about a modular concept. Its central and common building block is the open backplane standard: [[Backplanes and Standard Form Factors#CompactPCI Serial Space|CPCI Serial Space]] backplane. The ADHA concept is based on compliant CPCI-S-S modules that can be assembled and re-assembled into numerous and diverse offerings for on-board data handling applications and services. The ADHA concept provides endless possibilities for creative units with interoperability capabilities. The ADHA concept is materialized with versatile products offering compact, modular, interoperable, and interchangeable Data Handling Systems (DHS).  > [!Figure] > _A 6U ADHA unit containing modules. Credit: ESA_  > [!Figure] > _Example of a 6U ADHA module. Credit: ESA_ The ADHA units are based on 2 different sizes: 6U and 3U as defined in CPCI-SS. In an ADHA unit, a module is interfacing with other modules via its backplane. The ADHA backplane defined allows to building of different ADHA units based on a suite of ADHA modules. An ADHA-Module is a board, which is mounted and connected to the backplane by being plugged into a slot. Four different types of module profiles have been defined to be compatible with the ADHA backplane slots: - Module Profile A (power type) compatible with the backplane power module slots. - Module Profile B (system controller type with possibly SpW/SpFi Hubs) compatible with backplane system slots, backplane extended peripheral slots, and backplane peripheral slots. - Module Profile C (SpW/SpFi Hubs) compatible with backplane extended peripheral slots and peripheral slots. - Module Profile D (peripheral with 1 or 2 FCGs) compatible with backplane peripheral slots and backplane extended peripheral slots. The interfaces of the ADHA modules have been defined such modules of the same kind can be procured from different suppliers and mounted on different units without any modification. There are 5 different types of slots in an ADHA backplane: - Power module slots - System slots - Extended peripheral slots - Peripheral slots with 2 FCG (Fault Containment Groups) - Peripheral slots A 3U unit can welcome up to 14 modules as follows: - 1 power module in the power module slot NOMINAL - 1 power module in the power module slot REDUNDANT - 1 module in the system slot NOMINAL - 1 module in the system slot REDUNDANT - 1 module in the extended peripheral slot NOMINAL - 1 module in the extended peripheral slot REDUNDANT - Up to 8 modules in the peripheral slots. Different combinations are possible, e.g. 4 N modules and 4 R modules  > [!Figure] > _ADHA-3U unit with the maximum number of slotsADHA-3U unit with the maximum number of slots_  > [!Figure] > _Example application of an ADHA unit_ Are ADHA and SAVOIR trying to skin the same cat? The Advanced Data Handling Architecture (ADHA) and the Space Avionics Open Interface Architecture (SAVOIR) are both initiatives related to improving the design, development, and functionality of space systems, but they focus on different aspects of space mission architecture and have distinct objectives and scopes. The goal of ADHA is to enhance data efficiency, ensure high levels of data reliability and integrity, and promote scalability and standardization in data handling systems. This initiative is aimed at addressing the challenges posed by the increasing complexity and data volumes in modern space missions, ensuring that data management systems are capable of meeting current and future needs. SAVOIR, on the other hand, is an initiative aimed at defining a set of guidelines and standards for the development of avionics systems in space missions. The focus of SAVOIR is on promoting interoperability, reusability, and reliability of avionics components and systems. It seeks to establish a common framework that can be used across different missions and platforms, facilitating the integration of hardware and software components from various sources. SAVOIR covers aspects such as interface definitions, component specifications, and architectural patterns for avionics systems, with the ultimate goal of reducing development time and costs while enhancing system reliability and performance. All in all, ADHA is centered on data handling, encompassing the entire data lifecycle from acquisition to distribution. SAVOIR, in contrast, focuses on the avionics systems, including the hardware and software components that control spacecraft functions and operations. ## Sensor Open Systems Architecture (SOSA) The Sensor Open Systems Architecture, commonly known as SOSA, is a collaborative initiative that aims to create a common architecture for radar, electronic warfare, and signals intelligence systems. Initiated by the U.S. Department of Defense alongside industry and academic partners, the primary goal of SOSA is to develop standards that ensure interoperability and modularity in electronic warfare and defense systems. The essence of SOSA lies in its focus on fostering a modular approach to system design. This modularity is a great advantage as it allows for components from different manufacturers to be seamlessly integrated, creating systems that are both flexible and upgradable. The architecture defines standards for hardware, software, and mechanical components, ensuring that they can work together regardless of their origin. One of the key benefits of SOSA is that it facilitates faster and more cost-effective development of defense systems. By adopting a unified standard, the time and resources spent on ensuring compatibility between various components are significantly reduced. This not only speeds up the process of system development but also reduces overall costs. Furthermore, SOSA emphasizes the importance of system longevity and adaptability. In the fast-evolving field of defense technology, being able to update systems with the latest technology without having to overhaul the entire structure is invaluable. The interoperable nature of SOSA-compliant systems means that newer, more advanced components can be easily integrated as they become available. The SOSA architecture is mainly described in the SOSA Reference Implementation Guide (RIG), which elaborates on guidance provided in the SOSA Technical Standard. While the SOSA Technical Standard can be described as a "toolbox" for SOSA sensor component implementation, the SOSA RIG is essentially a "user guide" for the toolbox. The RIG provides a wide breadth of best practices deemed valuable by the SOSA Consortium Subject Matter Experts (SMEs), industry leaders, and a large sample of the user community with a vested interest in implementing the SOSA Technical Standard and expanding on SOSA concepts. The comprehensive level of detail provided in the RIG is suitable for instruction to new engineers and provides clarification to those more experienced in SOSA sensor design and integration concepts. As described in the SOSA Technical Standard, a SOSA sensor is comprised of a set of sensor components. There are two types of SOSA sensor components: - SOSA modules, which are logical building blocks that when realized implement specific functions and interfaces - SOSA infrastructure, which forms the building blocks that provide a platform for SOSA modules to execute those specific functions and interfaces. The taxonomy for SOSA sensor components is illustrated in the figure below:  > [!Figure] > _SOSA Taxonomy. Credit: SOSA_ The SOSA Technical Standard defines a set of rules for each sensor component. To instantiate, or implement, an SOSA sensor component, all rules for that sensor component must be met; where the requirements for SOSA modules describe the functions and interfaces that it must provide. Given that SOSA modules are logical building blocks, there are no specific implementation rules (either in hardware, firmware, software, or a combination of the three) that provide guidance. To ensure adherence, SOSA modules will undergo verification as to whether they provide the required functionality and follow the interface definitions specified. Implementation(s) of SOSA modules typically occur on SOSA infrastructure building blocks. It is important to understand that a SOSA module must conform not only to its own functions and interface requirements but also to the requirements of the infrastructure building blocks used to implement it. For example, if a SOSA module is implemented as functionality incorporated into a PIC, that SOSA module will need to conform to the SOSA module requirements and all associated common and specific requirements with the PICP. Likewise, if a SOSA module is implemented as portable software, that SOSA module will need to conform not only to the SOSA module rules, but the Run-Time Environment (RTE) rules for the use of operating systems, and the interaction infrastructure rules for calling the Transport API. The bottom line is that each SOSA module implementation will implement rules from the left side and right side of the taxonomy -- the rules associated with the SOSA module's functionality and interfaces, and requirements associated with the use of any hosted SOSA infrastructure. SOSA infrastructure components can be implemented solely with common and specific requirements associated with that component. For example, a supplier implementing a Plug-in Card[^84] (PIC) will incorporate all the rules associated with that PIC profile (PICP), including common requirements for form factor (3U, 6U), power, etc. It is important to note that software RTEs and inter-module transport infrastructure have their own associated requirements. Implementations of that infrastructure must conform to all the requirements for that SOSA sensor component. Note that there are separate rules associated with the users of an RTE or transport infrastructure API and the implementers of one. A SOSA module, as the user of an RTE or transport infrastructure (e.g., API), will have rules that an RTE or interaction infrastructure must implement the API functionality following the rules for that SOSA sensor component. For example, a FACE™ Operating System Segment (OSS) RTE must be implemented as a FACE conformant OSS Unit of Conformance (UoC). A SOSA module using the FACE OSS RTE must use the OS interface specified in the associated rule. One of the key goals of the SOSA Technical Standard is to constrain the large selection of OpenVPX Slot and Module Profiles to a minimum set that would form the SOSA PIC solution space. OpenVPX currently offers some 28 different 6U profiles (22 Payload/Peripheral and 6 Switch Profiles) and 63 different 3U profiles (39 Payload/Peripheral and 24 Switch Profiles), with most of these profiles offering user-defined pins. When Module Profiles, which define the protocols supported by each OpenVPX Slot Profile, are added to the mix this jumps to the many hundreds of possible options, and the user-defined pins mean the options are virtually unlimited. This large selection space and user-defined flexibility make avoiding vendor lock-in a virtual impossibility. The SOSA Technical Standard addresses this by defining a minimum set of Slot and Module Profiles with no user-defined pins (except for two special cases, that is). This minimum set of OpenVPX Slot Profiles and protocol-selection options means there is a much greater chance that an integrator can leverage COTS PICs and COTS or slightly modified COTS backplanes to quickly integrate a deployable system and can easily update or upgrade that system in the future. [^84]: SOSA PICs are based on OpenVPX. ANSI/VITA standards use the term "plug-in module" instead of PIC.