# Functional Architectures The figure below depicts a functional breakdown that includes the minimum number of functions for a spacecraft to perform its main (or master) function: “Operate a Payload in Orbit”. The main function flows down into sub-functions as depicted in the diagram. All the subfunctions contribute to the main function. These functional blocks can also be seen as *handlers*; i.e., they are supposed to take care of something. ![[Pasted image 20250119160407.png]] > [!Figure] > A functional decomposition of an avionics architecture However, this functional breakdown structure is totally immaterial. There is not a single mention of how the physical breakdown structure looks like. All those blocks in the figure above are not physical entities, but abstract blocks that ideally provide a function that the system needs for its global, core function. Function, by itself, is weightless and intangible, which is great news for designers because it makes the functional analysis very flexible. What makes designers’ life harder is the way the elements are put together to realize the function. Abstract functional architectures will not get the job done, so the design team must distribute functions across the physical architecture (i.e. allocate functions to physical blocks). Bear with me here that software can also count as “physical” in the sense that it is an entity (binary/object code) which is supposed to perform the function. Physical here means more “an entity which is implemented to execute the function in the operative environment” than actually physical in the sense that you can hold it in your hand. This is a point when it starts to be the right time for designers to evaluate whether to go [[Modularity|modular]] or not, hence the importance of functional analysis when it comes to modular thinking. It is from the functional breakdown structure that modularity can be evaluated most effectively. The game of connecting functions to physical/executable blocks is a many-to-many combinatorial challenge. Many functions can be allocated to one single physical/executable element, as well as one single function can be broken down to many physical/executable elements. This is the foundation of Integrated Modular Avionics, which we shall discuss in due time. Architectural decisions are always shaped by context and constraints. For example, cost is a common driver in avionics architectures, which undoubtedly sneaks in during the design process when it comes to function allocation. Mass is the other typical one, which makes a big difference in aerospace (fuel efficiency) and space (launch cost). This is a strong incentive to concentrate functions in as few physical elements of the architecture as possible (another driver of integrated architectures). Of course, integrated architectures come with risks. There are dangers associated with putting “all eggs into one basket”, mostly related to reliability and single point of failure. A reasonable failure analysis should be performed, and risks taken should be understood and communicated. ## Function-Structure Diagrams Crossing the boundary between the abstract functional analysis and the physical/executable architecture is never an easy task. When the functional and physical/executable architecture depart from each other and do not align one-to-one, two sorts of “universes” are spawn. It is important to keep visual clues about how those two domains (functional and physical) remain mapped to each other. By doing this, the design team can track design decisions which might be reviewed or changed later in the process. Concept maps can be used for this, there is no actual need to overcomplicate it, visually speaking. In the figure below, the boxes in blue are abstract functions and sub-functions, whereas the yellow blocks are actual physical/executable elements of the architecture. Note that this type of diagrams can accompany the early-stage analysis of requirements. Typically, requirements at early stages point mostly to functions and not to specific synthesis of functions (how those functions are realized). This means a concept map with the initial understanding of the functions required can be transitioned to a function-structure diagram as the architectural decisions on how the mapping of functions into physical blocks is performed. ![[Pasted image 20250109232153.png]] > [!Figure] > A simple function-structure diagram using concept maps # Avionics Architecture A very generic avionics architecture (in this case, of a spacecraft) looks as depicted in the figure below. The green boxes are different functional chains that provide some essential capability for the vehicle. Regardless of what type of application or mission the spacecraft is supposed to perform, those functional blocks are mostly always present. The yellow box called "payload" encloses the functionality of the actual application that gives a purpose to the mission, which can be comms, IoT, Earth Observation, et cetera. ![[Pasted image 20250108215740.png]] > [!Figure] > An overly generic avionics diagram of a spacecraft Note that some of the functional chains in an avionics system do not necessarily need to include a computer inside; they can be passive. For example, thermal control of a spacecraft can be passive (using insulation, paints, and radiators), hence computing will not be needed. What stands out from the figure is that spacecraft avionics needs a lot of interconnection. This means the functional chains must exchange data with each other to couple/combine their functionalities for the global function of the spacecraft to "emerge". That data is in the form of commands, telemetry, or generic data streams such as files, firmware binaries, payload data, etc. Avionics architectures are generally recursive in the sense that functional chains will also have internal composition as well that will (in most cases) also require interconnection and use private data buses. ![[Pasted image 20250108215848.png]] > [!Figure] > Attitude control functional chain as a member of the general avionics architecture. Note the private data bus inside the functional chain, which is inaccessible from the main bus Then, we can see that the coupling of the system's main functions strongly depends on an aggregation of communication buses. It is clear that data buses are probably the most important functional coupling mechanisms of any avionics architecture. A vehicle with poor interconnection between its functional chains will see its performance and concept of operations greatly affected. This is a factor that is usually overlooked during the design phase: low-speed, low-bandwidth buses are chosen at the early stages of a project, only to find out later that the throughputs are insufficient to sustain the overall required system performance. Changing data buses at later stages can be costly, both in money and time. With [[High-Speed Standard Serial Interfaces|high-speed serial buses]] and high-performance processors dropping prices and being more and more accessible, there is no reason not to design the avionics to be highly interconnected by using high-speed data connections. ## Avionics Architecture Evolution The application of digital computing technology to aerospace avionics systems has occurred rapidly as vehicle performance and complexity have increased. In commercial aviation, the increase in air traffic coupled with modern satellite navigation systems has demanded higher density route structures and improved surveillance systems with a necessary increase in onboard computational power to plan and perform complex flight paths with a high degree of precision. This has been facilitated by advances in digital avionics technology in the areas of processing, software development and network-centric digital communications, enabling aircraft systems to be integrated on a much larger scale. Aircraft avionics systems have grown rapidly in terms of capability and complexity, taking full advantage of digital processing technological enhancements. Technology has brought improvements in terms of increased performance, computing power, complexity and reliability, although with an increase in cost. Other benefits include a decrease in weight, volume, power consumption, wiring and support costs. The figure below portrays how avionics architectures have evolved from the 1960s to the present time. The key architectural steps have been: - Distributed analog architectures: Distributed analog avionics architectures are characterized as a set of discrete or ‘point solutions’ to individual avionics subsystems, each designed and implemented in relative isolation from one another and certificated separately. The subsystems equipments are interconnected by hardwiring (this architecture pre-dates digital data buses) and results in a huge amount of aircraft wiring. The system function is implemented in hardwired circuitry and interconnections, and hence the system is extremely difficult to modify. - Distributed digital architectures: The maturity of digital computing devices suitable for vehicle control use soon saw digital computers replace their earlier analogue equivalents. The digital computers as installed on these early systems were a far cry from today, being heavy, slow in computing terms and having very limited memory capacity. - Federated digital architectures: The federated avionics systems architecture recognizes that the total vehicle avionics systems functions are interrelated and interdependent. The commonality of approach facilitates the sharing of information between previously disparate systems, enhancing the whole functionality of the avionics system. We now see related systems being grouped into domain areas or functional chains and data exchanged between equipments within the domain area on the local data bus network. Functional chains are interconnected at a higher level to pass global information from domain to domain. In this approach, one function typically maps to one computing element. - Integrated modular avionics architectures: The aerospace industry understood that the classical concept of “one function maps to one computer” could no longer be maintained. To tackle this issue, the integrated modular avionics (IMA) concept emerged. Exploiting the fact that software does not weigh anything in and of itself, IMA allowed retaining some advantages of the federated architecture, like fault containment, while decreasing the overhead of separating each function physically from others. The main architectural principle behind IMA is the introduction of a shared computing resource which contains functions from several Line-Replaceable Units ([[Units, Chassis and Racks#ARINC-600|LRUs]]). This means function does not directly map one-to-one to the physical architecture, but one physical computing unit (CPU) can share its computing resources to execute more than one function. > [!important] > A sort of contradiction surrounds the IMA concept. It could be argued that IMA proposes an architecture that technology has already rendered obsolete: centralized architectures. With embedded processors, memories and other devices becoming more reliable and less expensive, surely this trend should favor less rather than more centralization. Thus, following this argument, a modern avionics architecture should be more, not less, federated, with existing functions “deconstructed” into smaller components, and each having its own processor. There is some plausibility to this argument, but the distinction between the “more federated” architecture and centralized IMA proves to be debatable on closer inspection. A federated architecture is one whose components are very loosely coupled—meaning that they can operate largely independently. But the different elements of a function—for example, orbit and attitude control—usually are rather tightly coupled so that the deconstructed function would not be a federated system so much as a distributed one—meaning a system whose components may be physically separated, but which must closely coordinate to achieve some collective purpose. Consequently, a conceptually centralized architecture will be, internally, a distributed system, and the basic services that it provides will not differ in a significant way from those required for the more federated architecture. > Another contrarian point of view is that neither centralized IMA nor the more federated architecture offers significant benefits over current practice; the still present federated architecture has been validated by experience, and modern hardware technology will reduce its cost penalty—so there is no reason to change it. The argument against this point of view is that it takes a very narrow interpretation of the costs associated with the current architecture and therefore grossly underestimates them. One neglected cost is safety: the federated architecture has the advantage of natural fault containment, but it imposes a cost in poorly coordinated control and complex and fault-prone interfaces. See #ref/Rushby for a great analysis on IMA) ![[Pasted image 20250108221618.png]] > [!Figure] > Evolution of avionics architectures (source: #ref/Moir ) ![[Pasted image 20250108222737.png]] > [!Figure] > Federated vs Integrated Architectures > [!attention] > This section is under #development