Automated generation of aircraft on-board system architectures and filtering through certification specification requirements

On-board systems represent an important part of an aircraft having a noticeable impact on mass and fuel consumption, among others. New innovative systems might increase the performance of the new generation of aircraft. Aircraft on-board system architectures are defined by the different subsystems, components and connections among them. The big amount of possible combinations usually creates a huge architectural design space that requires automation in order to be properly explored. Certification aspects can be used as a filter in early design stages of on-board systems, this allows to discard some architectures if they are not compliant with the certification specifications. The discarded architectures do not need to be sized and calculated, saving computational time. The proposed methodology shows how to create this link between on-board system architectures generation and certification rules. Results show an application case regarding the modelling of a flight spoiler system. Several architectures are automatically generated from the design space and then automatically filtered by the certification specification rules. This achieves a preliminary certification of innovative on-board system architectures and allows certification aspects to also drive the design process.


Introduction & State of the art
The aviation industry is developing new aircraft concepts in order to face the challenge of becoming more environmentally friendly in the near future.These new aircraft concepts (e.g., hybrid-electric propulsion, hydrogen) are leveraging new technologies that lead to innovative on-board system architectures (e.g., more-electric or all-electric [1]).On-board systems are an important part of an aircraft, having a noticeable impact on the total mass and fuel consumption.The new generation of aircraft might leverage the advantages of new innovative systems, such as better performance, lower weight, higher reliability, etc... Aircraft on-board system architectures are defined by the different subsystems, components and connections among them, and they include all the power generation, distribution and consuming systems.An issue that arises when defining on-board system architectures is that the huge amount of possible options (i.e., millions or more) usually creates an enormous architectural design space that requires automation in order to be properly explored.Modelling the design space, and the system architecture, can be a tough task.For that, system architecting principles are used.A system architecture defines the structure and behavior of a system.Decomposing the architecture in terms of its functions to be fulfilled carries some benefits.This functional breakdown is generic to any architecture alternative and it does not suggest any architecture concept itself.The result is a design space that is generic and without bias.In the past, the definition of the architecture of a system was done based on experience, or by some trade-off analysis.However, this did not provide detailed information about the performance of the system with that architecture.This is known as the knowledge paradox: in the early design stage much freedom is available to modify the existing design, but not much knowledge of the system is available [2].Better exploring the design space during preliminary phases helps to mitigate this paradox and to have more detailed results during conceptual design, this supports the decision making.The formalization of a design space, and an architecture, is a challenging task but some available methods allow to properly define and explore it in order to find the most optimal solutions to the problem [3].Differences in performance among architectures are typically assessed during preliminary design of on-board systems [4,5], several tools exist in the industry and literature [6].This allows to have a first insight to decide whether the new architectures are promising or not.However, other disciplines such as certification and maintenance should also be considered in order to understand the potential of new concepts.This links to the concept of concurrent engineering.It is a methodology that aims at improving product development time, which for aircraft is a priority, by creating a multidisciplinary framework with all the disciplines involved in the design process, all of them explored in parallel [7].Some key aspects of this include managing complexity by splitting the development into domains [8] (e.g., supply chain, manufacturing , maintenance...).This paper focuses on the certification discipline (i.e., safety analysis, reliability, compliance with the certification specifications).The importance of including it during early design stages has been highlighted in other studies [4].The exploration and modeling of the certification discipline during preliminary design is currently a gap in literature, and the focus of this study.Other current studies are approaching this direction of research [9].Some guidelines for aircraft systems certification are contained in technical standards like ARP4761 or ARP4754.The main issue is that most of them need a too high level of detail to be performed at these stages (e.g., FMECA, FTA).They also cannot be easily automated owing to the huge amount of information that they require.The reliability block diagram (RBD) technique [10] was chosen since it makes automation possible.Furthermore, this method provides quantitative results (reliability of a system) which makes it more feasible to be integrated in an optimization framework.Minimal paths method is one of the most common ways to solve a RBD [11], however this method does not allow easy automation, so the methodology proposed in [12] is suggested.This method is supported by the specific standards for reliability block diagrams [13].The biggest limitation is that some RBD configurations might not be solvable and a simplification of the system might be needed.This does not arise an issue during early design phases since posterior and detailed safety and reliability analysis will determine the final results of the architectures.Summarizing, including certification aspects in early design stages of on-board systems carries some advantages.Certification can be used as a filter that allows to discard some architectures if they are not compliant with the certification specifications.These discarded architectures do not need to be sized and calculated, saving computational time.Hence, certification now affects the design and this can potentially constraint the feasible solutions.The main objectives of this paper are: • To show how certification aspects can be included in early stages of aircraft on-board system architectures design, focusing on the CS-25 requirements.• To indicate how the evaluation of this discipline can be automated and connected to a systems architecting framework.• To show the potential and benefits of the methodology through a flight spoilers system application case.

Methodology & Implementation
The proposed methodology shows how to create a link between on-board system architecting and certification rules.The methodology is represented in figure 1.A huge number of architectures is automatically generated and then filtered following a set of rules extracted from the certification specifications.CS25 [14] is used for the application case but other certification specifications could be used following the same methodology.Some of these rules are qualitative and others quantitative.One quantitative rule states that the safety of a system must be assessed and provides a minimum value of reliability that must be ensured.In order to estimate this, the reliability block diagram technique is used [13] and automated [12].Examples of qualitative rules are those compelling the existence of back-up systems for the power generation or those restricting single component failure leading to a whole system failure.The methodology is now divided into three parts and explained into more detail.
Figure 1.Methodology schema for on-board system architectures filtering through certification specification requirements

Architectural design space modelling
The first step is to model the design space of the system of interest.The objective of it is to later perform the architectures generation.The design space is modelled following system architecting principles and it represents the architecture decisions that are involved in the later optimization problem.It is build by identifying the top function that the system needs to fulfill, from here different components are mapped to that function and new induced functions are linked to those components which need again new induced functions.Additionally, information about components is also included (e.g., number of instances, attributes).As a result, the design space is modeled from a functional perspective.For more details on how to model a design space the reader is referred to [2,3].An in-house software called ADORE [3] is used for the implementation of this methodology.It allows to graphically create the design space supporting the design process.It also links the design space to the optimization problem [15].Following the methodology previously explained, functions are modelled and different components can be inserted as potential fulfillers of these functions.If there is a function that can be fulfilled by two or more components, a decision node is inserted to represent the choice of architectures.This way, the architectural design space is created by inserting decision nodes in certain situations.Decisions are automatically identified, and they are directly mapped to the architecture decisions in the optimization problem [16].Complex concepts can be modelled.From the design space, all the different possible physical architectures of the system can be obtained.Hence, once the design space is modelled the generation of architectures is automated.

Architectures certification filter
After the architectures are generated they are filtered following certain certification specification regulations.This part of the methodology shows how to create a filter that reads a physical architecture as an input and decides whether the architecture is potentially certifiable or not.CS-25 [14] is chosen since it covers the majority of aircraft of interests (i.e., large turbinepowered aircraft).The certification specifications do not provide with direct or specific rules for the on-board system architectures of an aircraft.This means that there are no direct rules about, for instance, the number of actuators or redundancies that a specific component should have.They give more general and generic requirements about the systems safety and reliability.These generic requirements can then be used and applied to the architectures.Three major requirements were identified for the purpose of this analysis.These are the ones with a bigger impact on an architectural level and are in line with the ones presented in [12] and are now named and listed: • Requirement 1: Back-up power source in case of engines loss.
The first requirement comes from CS 25.671(d).It specifies that there must be at least one back-up system to guarantee the correct functioning of the flight control system and landing gear in case of loss of all engines.For existing aircraft this is usually ensured by adding an auxiliary power unit (APU) or a ram air turbine (RAT) connection to the specified systems.But other solutions with other non-engine-dependant redundant power sources are also feasible.The second requirement comes from CS 25.1309(b)(1)(ii).It indicates that the single failure of a component must never lead to the failure of the whole subsystem.This requires the presence of redundancies, both at component and power lines level.This requirement is emphasized in further paragraphs through the CS25.The third requirement comes from a combination of CS 25.1309(b)(1)(i) and AMC 25.1309(7.c)(1)(iv)).It establishes that catastrophic failure conditions must occur with an average probability lower than 1×10 -9 per flight hour.The reliability block diagram (RBD) technique is suggested in order to assess this requirement.The main issue arises here.The RBD architecture of a system is not the same as its physical architecture.Furthermore, one physical architecture can represent several functioning modes that translate into several RBDs.A consistent and automated way to translate the architectures from physical to RBS is needed, as well as a way to automatically solve the resulting RBDs.More details about this part of the methodology are explained in section 2.2.1.
The implementation of this filter was performed using ACOBS (Automated Preliminary Certification of Aircraft On-Board Systems), a python tool developed specifically for this study.This tool reads as input the architectures generated by ADORE and provides as an outcome the result for each of the three requirements previously explained.Inside the tool the architecture gets automatically transformed into a RBD following the rules explained in section 2.2.1, then it checks each of the three requirements.For the first one the tool automatically cancels all the lines connected to the engines and checks if there is still at least one back-up system providing power.For the second one it iterates several times making each of the components fail and controlling if the main function can still be fulfilled.For the third one it reads a reliability block diagram as input and provides the probability of failure of it following the model presented in [12].The failure rates of each of the components need to be given as input.If the probability of failure is higher than the one given by the normative, the code returns a warning.The main problem with this is that the whole calculations depend directly on the failure rates estimation, and this information is usually not public or is outdated.Comparing the results with a fixed value makes the filter non reliable.An alternative is suggested.The design space system is run once with an architecture of a certified reference aircraft (e.g., if the aircraft of study has a MTOM of 78 tons the A320 can be chosen as reference aircraft).The whole methodology is executed for that reference architecture with the estimated failure rates, the resulting probability of failure is saved as the reference value.Other architectures are run afterwards, if their probability of failure is higher that the reference one it means that the new architecture is not potentially certifiable.If the probability of failure is equal or lower, then the architecture passes the filter.And example of this whole process is shown in section 3.

Reliability Block Diagram:
In order to solve a RBD one can follow the guidelines expressed in the standards [13].Following them it is noticeable that one RBD represents one functioning mode of the system (i.e., one top function as defined in section 2.1).Hence, if the system of interest fulfills several functions, one RBD does not represent the whole system.For instance, a flight control system performs different functions like roll, yaw or pitch control.A different RBD can be obtained for each of these functions.Another important aspect to consider is that RBDs do not only have series and parallel configurations, complex systems might use more complicated connections among components that cannot be represented by these.This configurations complicate the RBDs solving and their translation from physical architectures.They still can be solved using the models in [12].It can be noticed that RBDs are reduced to a list of components connected through nodes.How the nodes are connected determines the final RBD configuration.Some key guidelines are needed in order to translate from a physical architecture to its RBD configuration. Figure 2 shows the process.First a system of interest is chosen.In this case an example from [17] is taken.It represents a gas pipeline that has two servo-valves that are able to close it.Each of the valves are connected to a logic solver that reads the pressure from its corresponding pressure sensor.One extra redundancy is added, if the second servo-valve fails the second logic solver is able to send the closing command to the logic solver 1.As a result the architecture on the left side of figure 2 is obtained (the visualization was obtained with ADORE [3]).From this point the methodology is applied, components are directly mapped from the physical architecture to the RBD.Functions are mapped to nodes (represented with red numbers) since they define the connections among the components.It is noticeable how the RBD is usually build from the right side (top function, node 1) to the left (node 0), where all the final components are located.Reading the RBD the user can see the list of components that need to function in order to achieve the top function.In this simple case there are three paths: SV1-LS1-PS1 or SV2-LS2-PS2 or SV1-LS1-LS2-PS2.It is worth mentioning that this example shows only one architecture, not a whole design space.

Closing the feedback loop for optimization
The certification filter is connected to an optimizer in order to be automated.This analysis stops right after the certification filter but the advantage is that other disciplines could be added after it (e.g., performance or maintenance).Since the scope of this study is to provide the guidelines to create the certification filter, the optimization loop is closed based on results from the filter itself, leaving further analysis to connect this methodology to other models.The design space is given as the design variables, they represent each of the different possible architectures.As constraints the three requirements included in the certification filter are used, being the back-up condition, single failure case and minimum reliability.If just one of the three conditions is not met, the filter results in a not-passed condition and the architecture is discarded as non-feasible.As an optimization objective the main idea is to use metrics from posterior analysis, as the ones commented before.In this study the probability of failure of the system is chosen, being the lowest the most optimum case.Since some of the design variables are discrete, genetic algorithms are recommended.Regarding the implementation, ADORE is able to support the whole optimization process.The certification filter is connected to it and the optimization quantities are selected.The whole optimization process works as follows:

Application case: flight spoilers
A system of flight spoilers is modeled following the methodology.Ailerons can also be included if the whole roll function of the flight control system needs to be assessed.This increases the number of architectures so only the flight spoilers were included in the model for simplicity.First, the design space is modeled with ADORE.The user can select the number of flight spoilers per wing from 2 to 5. The actuator type of each can also be individually selected between a classic hydraulic actuator or a electro-hydrostatic one (EHA).If a hydraulic is selected the function needed is "provide hydraulic power" while if the EHA is chosen the derived funtion is "provide electric power".This defines to which kind of distribution line the actuator needs to be connected (i.e., hydraulic or electrical line).If during the actuator selection no hydraulic actuator is selected, then the electrical system would not appear since it is not needed.This does not mean that there is no electrical system since other systems might still need it.Regarding the hydraulic system, a maximum of three lines is modeled.Two of them have the possibility to be connected through a power transfer unit (PTU) and they all can be connected to engine generators, electric motors or a ram-air turbine (RAT).The electrical line is done in an analogous way.Two of the lines can be connected to the generators or auxiliary power unit (APU) as redundancy while the third line is connected to the RAT.A maximum of three lines is created for each of them, still all actuators can be connected to just one or a combination of lines.The total number of decisions is 23, providing a total of more than 3 thousand million architectures.As reference, if the posterior evaluation of one architecture takes only 1 second it would take 103 years to analyze all of them.If the ailerons were added the growth in possible combinations is exponential.The need of filtering and optimization is quite obvious.The architectural choices are the design variables of the optimization problem.The three certification requirements are selected as constraints, in this case they result in just a "passed" or a "notpassed" feedback, given as a 0 or a 1.The single-objective optimization objective is the probability of failure of the architecture.As explained in the methodology, the probability of failure is based on a reference aircraft.In this case the A320 is selected.The result is divided by the reference probability of failure.The final value is 1 if the same probability of failure as the A320 is found.Higher than 1 would mean that the architecture fails more often than the reference architecture, so the minimum reliability constraint activates and the architecture is discarded.Every value between 0 and 1 corresponds to a valid and feasible architecture.Components failure rates are also needed.They can be provided directly inside ADORE by assigning quantities of interest to the components.The failure rates values were taken from the Quanterion Automated Databook (NPRD-2016, FMD-2016, EPRD-2014).This data is usually sensitive and companies do not share it, as a result most of the components in the database are military.Still, as a first approximation this database provides enough information to carry out the study.
ADORE allows to automatically generate architectures once the design space has been modeled and all components have their corresponding failure rates.Each of the architectures is given to ACOBS, were the constraints are calculated.The ones with failed constraints are discarded and, among the resulting architectures, the one with lower probability of failure is considered to be the optimal of that run.Genetic algorithms are used.Different optimum architectures are found by changing the number of generations and population size.However, it can be noticed that when running a high number of generations the results go towards two tendencies.The first one is adding as much spoilers and lines as possible, which makes sense since more redundancies results in a higher reliability.The second one is towards adding more electric components, since their failure rates are lower.Several optimization runs were performed.The longest one analyzed a total of ten thousand architectures (one thousand generations with a population size of ten individuals each).The architecture with the lowest probability of failure has five flight spoilers per wing, connecting one to the green hydraulic line and the rest to electric lines.The green line is connected to the yellow line through the PTU.The three electric lines are connected to the engines, APU and RAT.The result are in line with the expectations.

Conclusions
The huge amount of possible solutions during on-board system architectures design entails the need for automation in order to properly explore the design space.Including certification aspects in early stages of design allows to discard some of the architectures if they are not compliant with the certification specifications.Thus certification drives the design process and can be used as a filter.The methodology presented in this study shows how to properly create the design space for a system of interest.A certification filter based on the CS25 is created, explaining which rules should be applied to aircraft on-board system architectures.This filter serves as a preliminary certification of the different architectures that can be created for the system of interest.The methodology is completely automated.Several architectures are automatically generated from the design space and automatically filtered by the certification specification rules, the ones with failed constraints are discarded.These rules are based in three requirements.One is the minimum reliability of a system established by the normative.Other implicates the existence EASN-2023 Journal of Physics: Conference Series 2716 (2024) 012044 of back-up systems in case of loss of all engines.Another one provides a minimum number of redundancies so that the single failure of a component does not compromise the safe functioning of a whole system.The reliability block diagram technique is used and automated to estimate the reliability.Results show an application case regarding the modeling of a flight spoiler system.Several architectures (i.e., thousands) are automatically generated from the design space and then automatically filtered by the certification specification rules.The remaining architectures are preliminary certified.Further work could include other disciplines after the certification, like manufacturing or maintenance.This would also create new optimization objectives transforming the framework into a multi-objective optimization.

Figure 2 .
Figure 2. Example of methodology process from system of interest to physical architecture to reliability block diagram configuration