Rolf Johansson
email: rolf.johansson@sp.se

Jörg Kaiser
email: kaiser@ivs.cs.uni-magdeburg.de

Antonio Casimiro

Renato Librino
email: renato.librino@4sgroup.it

Kenneth Östberg
email: kenneth.ostberg@sp.se

José Rufino

Pedro Costa
email: pedro.costa@gmv.com

Antonio Casimiro

António Casimiro

An Architecture Pattern Enabling Safety at Lower Cost and with Higher Performance

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.



Abstract-In both avionic and automotive systems, it might become very costly and/or restricting the functional performance, to prove functions safe in all operational conditions and for 100% of the mission time. This is especially true if the quality of sensor data and of communication data may vary very much. One way to solve this trade-off paradox is to leave part of the safety assessment from design-time to run-time. This paper proposes a general architectural pattern for this, and also how to instantiate this pattern in Integrated Modular Avionics (IMA) for the avionic domain, and in AUTOSAR for the automotive domain. The solutions imply some extensions of ARINC 653 and of AUTOSAR respectively, but they are not in conflict with the existing concepts. The proposed solutions are also fully in-line what is prescribed by the standards for functional safety of the two domains.

Index Terms-Safety Integrity, IMA, AUTOSAR,

I. INTRODUCTION

n both the industry fields of Avionics and of Automotive, there has been established a norm of having integrated, rather than federated, Electrical/Electronic (E/E) architectures. In the avionic field this is called Integrated Modular Avionics (IMA) [START_REF]AEEC: Design guidance for Integrated Modular Avionics[END_REF] and is today often following the ARINC 653 specifications [START_REF] Aeec | Avionics application software standard interface, part 1required services[END_REF], and in the automotive field it is the AUTOSAR specifications constituting the state-of-practice.

One advantage with an integrated architecture is that it is possible to increase the number of vehicle functions and still decrease the number of computing nodes, often called LRUs (Line Replaceable Units) or ECUs (Electronic Control Units). Different functions may be realized by architectural elements (sensors, actuators, computing components, communication components, etc.) that may be shared among several functions. However, in the transition from a federated to an integrated pattern, the way to ensure functional safety has become more complex. Instead of directly transfer the safety arguing responsibility to a node supplier, the integrated pattern calls for a component-based approach in both the design itself and in the safety case generation. Furthermore, achieving functional safety is a goal that often is in conflict with high performance and low cost.

In this paper we outline an architectural pattern that is possible to apply for both IMA and AUTOSAR, and that helps to resolve the paradox of getting functional safety together with low cost and high functional performance.

II. ARGUING SAFETY

The problem how to prove that a solution is functionally safe, is defined specifically by applicable standards in each domain. For road vehicles, functional safety is defined by ISO 26262 [START_REF]ISO: Road vehicles -Functional safety -International Standard ISO 26262[END_REF], and the instruction how to apply component-based safety arguing is so far limited to what is stated as Safety Element out of Context (SEooC) in the informative part 10 of the standard. For the avionic domain there are several applicable standards. The IMA perspective is found in RTCA/D0-297: "Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations". This standard refers to other standards such as SAE International's Aerospace Recommended Practice (ARP) 4754 on "Certification Considerations for Highly-Integrated or Complex Aircraft Systems", and SAE ARP 4761 on "Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment". These in turn refer to RTCA/DO-178: "Software Considerations in Airborne Systems and Equipment Certification".

On a high level, one can say that arguing safety is similar in the two domains. They both rely on a Hazard Analysis & and Risk Assessment (HARA) of the vehicle functions, resulting in required risk reduction by means of safety integrity levels for the realizing architectural components. In the automotive domain the safety integrity levels are called Automotive Safety Integrity Level (ASIL) [START_REF]ISO: Road vehicles -Functional safety -International Standard ISO 26262[END_REF], and in the avionic domain they are called Development Assurance Level (DAL) [START_REF]SAE: Guidelines for Development of Civil Aircraft and Systems[END_REF]. The default alternative is to use a fault avoidance argumentation based on the fact that all used components, each conform to the required safety integrity level. This can be combined with a fault-tolerance argumentation based on introducing redundancy and hence lower the required integrity level of the components. To integrate components having different integrity levels on the same platform, freedom of In both domains, the determination of safety integrity level is based on a severity classification of the possible failures of the vehicle function under consideration. In the avionic domain this directly leads to one of the Development Assurance Levels in the interval between A (required by a catastrophic failure) and E (when there is no safety effect required). In the automotive domain the severity classification of the vehicle function has to be evaluated together with assumptions on how often such a failure is critical among the driving scenarios, and with an assumption how well the driver can compensate for the failure. These three factors together, lead to an Automotive Safety Integrity Level in the range between ASIL D (highest requirement on risk reduction) and QM (no requirement on risk reduction).

In both domains, a high requirement on risk reduction implies a high safety integrity level requirement (formulated by DAL or by ASIL) on the used components. It is needed to show that the vehicle and its components fulfill all requirements on safety integrity levels. This assessment is completely done in design-time, and shows that the vehicle always is functional safe with respect to the complete scope of the functions considered in the Hazard Analysis.

IV. EXTENDING THE ARCHITECTURAL PATTERN

Building vehicles where the complete scope of all functions are proven safe in all operational conditions and for 100% of the mission time, might become very costly and/or restricting the functional performance. One way to solve this trade-off paradox is to leave part of the safety assessment from designtime to run-time. By letting the architecture itself in run-time measure the provided safety integrity levels from the components, it can enable adjustment of the different functions such that their required safety integrity levels are met. Let each vehicle function have a number of predefined levels of performance (levels of service), for which the resulting hazard analyses are different. If we then in run-time can measure for which levels of service/performance the safety integrity requirements are fulfilled, the vehicle can be proven safe once we can guarantee that all functions always are forced to a level of service/performance that is considered safe. What we need for this is an architectural pattern enabling the complete measuring of the safety integrity levels of the architectural elements, and a way to ensure that all functions operates on a level of service/performance that can be proven safe.

This paper shows the general architectural pattern, and also outlines how it can be instantiated into the state-of-practice in the integrated architecture of the domains of automotive (AUTOSAR) and of avionics (IMA realized by ARINC 653), respectively.

A. Design-Time vs. Run-Time

Even if the strategy proposed in this paper is that there is a run-time check of what safety integrity levels that are met in order to match with the appropriate performance level, all possible results have to be assessed in design-time. In both the avionic and the automotive domain, a complete functional assessment has to be done in design-time according to the respective reference life-cycles. The solution presented in this paper is fully aligned with this. When we say that we leave part of the safety assessment to run-time, this implies that all the possible alternatives for performance levels and also the mechanisms to determine the right levels, all are assessed in design time.

B. Relation to functional safety standards of today

In both DO178 and in ISO26262, there is a concept of integrity levels (DAL / ASIL), to allocate requirements on the reference life cycle in order to argue sufficiently absence of systematic design faults. When we suggest having several levels of performance implying different required safety integrity levels on the output of some components, this implies that the DAL/ASIL applicable for the design of each component will be the highest safety integrity level among the possible ones. The concept of adjusting the levels of performance to the run-time available safety integrity levels is hence not primarily applicable to handle systematic design faults, but to take care of the varying quality of data due to the varying amount of redundancy sources and of varying quality of sensors and communication links.

Especially from the software design point of view, we assume that what is prescribed as needed to argue for the highest applicable safety integrity level, still must be implemented as well in the application components as in the platform software (ARINC653/AUTOSAR). This requirement of design according to the highest safety integrity level is of course applicable to the redundancy mechanisms checking the quality of data, and to the platform mechanisms determining the appropriate level of service/performance. This is further elaborated in the section below: A general pattern.

The consequence of having a number of different levels of performance is that the Hazard Analysis and Risk Assessment has to be done completely for each considered level. The stages prescribed in ARP4754 or ISO26262 part 3 thus have to be done not only for the functions, but for each level of performance for each function. Furthermore, each transition between two levels of performance has to be considered, as elaborated below in the section: Scalability and timing.

Regarding the safety standards applicable today in the domains of avionic and automotive, we conclude that they are fully in-line with both the concept of several levels of performance, and with the architectural pattern we outline in this paper.

C. Relation to existing patterns for mixed criticality

Mixed criticality [START_REF] Brade | Validity-based failure algebra for distributed sensor systems[END_REF] is the concept of allowing applications with different levels of criticality (safety integrity) to co-exist on the same system. In both ARINC 653 and in AUTOSAR there are mechanisms to deal with this problem. The assumed problem to deal with is to guarantee freedom of interference between application components designed to different levels of safety integrity. The solutions in both ARINC 653 and in AUTOSAR are to provide mechanisms for handling time and space partitioning.

However, when introducing several levels of performance, each implying different requirements on safety integrity levels of the output of some components, this is not the classical problem of mixed criticality. Even if we have a mixture of different levels of safety integrity among the components coexisting on the same platform, their requirements on the safety integrity of the absence of systematic design faults are all on the same level (the highest among alternatives). Hence we do not need to prove freedom of interference between components designed according to different DAL or ASIL, because that is not the case. All components used for a certain function are designed according to the safety integrity level that is applicable for the highest level of performance.

The mechanisms for enabling time and space partitioning are of course still important when arguing safety, even in our proposed pattern, but they are not affected by the introduction of several levels of performance with different safety integrity level requirements on some data signals.

D. Scalability and timing

Given the fundamental idea of leaving part of the safety assessment for the run-time, raises potential issues of scalability and timing.

Scalability issues stem from the fact that some system resources will be required for performing the run-time safety assessment. For instance, it will be necessary to collect measurements of available integrity levels, and it will be necessary to store information (defined in design time) concerning the safety integrity requirements for each level of service. This has essentially practical implications (availability of enough memory and computing power), which could limit the applicability of the approach. Fortunately, the effective requirements grow linearly with the number of components for which integrity has to be assessed, which is also limited by the available resources. In fact, the additional resources required for assessing safety in run-time are necessarily a very small fraction of the resources required by the components itself.

Timing issues are more important in this context because it is necessary to argue about functional safety, for which they have to be considered. As mentioned before, in design time it is necessary to assess, for each function, that it will perform safe in each possible performance level. But this is not enough. Given that, for each function, there will be run-time changes of the performance level, the analysis must take into account the time that it takes to complete these changes. For instance, if in run-time it is detected that some component is not performing with the required integrity level, then it will be necessary to change the performance level of all the functions that are affected by this integrity degradation, and this has to be done within some limited amount of time. Otherwise, the functions would continue to perform in some inadequate level for an uncertain amount of time, clearly outside the safety analysis performed in design time.

The general pattern must hence provide the means to address these timeliness requirements. In addition, it is necessary to discuss the implications of the (bounded) amount of time that is necessary to change the performance level of some function. A sufficient condition for ensuring timely detection of changes in the safety integrity levels, and consequent timely change of performance level, is that it is possible to perform a timing analysis of all the involved system components, deriving upper execution bounds. In particular, this includes the component responsible for performing the safety assessment, which is always involved in the process. If some function has to be performed with some minimal performance level, then it must also be possible to perform such timing analysis for all the implied components. The time that will be necessary to switch among different performance levels will typically be close the execution periods of the system components. In comparison with the typical latency of physical processes (such as braking, deviating from an obstacle, etc), these periods are much smaller. This means that the safety analysis will be, for the relevant part, still valid. In any case, the time that it takes to perform a change in the performance level can also be considered in the design of the functions, so that this is accounted in safety margins.

V. A GENERAL PATTERN

Each vehicle function is realized by a set of interconnected sensors, actuators and software components. The software components have an interface making them possible to be allocated on any platform node. The outputs of every sensor, and of every software component, are duplets consisting of both the nominal output and of an attribute stating the estimation of the corresponding safety integrity level. All redundancy mechanisms in the architecture such as: sensor fusion, voting, consistency checking, etc., are evaluating the consistency of the nominal values and calculates a resulting determination of the safety integrity level value. All safety integrity level values of a computing node are checked by a safety manager that is part of the platform specification. The safety manager compares in run-time that each provided safety integrity level of every output value, is high enough for the current scope of vehicle functions. If some of the provided safety integrity levels are too low, the safety manager tells the application mode managers to change to a level where the respective functions are considered safe. If all provided safety integrity levels are high enough for a higher level of service/performance than the actual for some functions, the safety manager tells the application mode managers to change accordingly.

A. Derivation of the Safety Integrity Attributes

As argued before, the extension of safety assessment from design-time to run-time allows for relaxing overly restrictive assumptions about the required integrity status of the overall complex control systems. However, it requires the continuous monitoring and evaluation of the integrity attribute during runtime. Fig. 1 shows that for every signal generated by a component, there is a complementary output that provides an integrity level attribute. Roughly, this attribute represents a measure for the integrity of the respective signal produced by a component.

When checking against allocated safety requirements, this estimation needs to be done against the defined discrete levels of the applicable standard. For both the standards we have five levels to consider. However, when deriving the safety integrity attributes we may use more finegrained estimations. In this paper we call such a more finegrained value, the Validity of a signal.

The assumed structure of a complex component comprises the acquisition and computational components from a sensor that captures a real-world entity to the component that outputs an application relevant data element (signal). The architectural element outputs the nominal signal (V) together with an integrity attribute (I) that enables the safety assessment at run time. To generate the integrity attribute, the component needs a self-assessment mechanism. Further, a nominal value affected by a failure may pass a filter to mitigate or mask the effect. We therefore distinguish between a detection mechanism and a filter mechanism. The checking mechanism detects a failure without affecting the respective signal. It modifies the integrity attribute only. The filter is a general abstraction of a component that mitigates or eliminates the effect of a failure. Typically, detectors and filters are integrated in a fault-tolerance mechanism. We separate the aspects of awareness and treatment because these are different concerns and the separation allows for more freedom of design. e.g. omitting a filter completely in the component for handling the failure in a subsequent stage. Fig. 2 depicts this general structure of such an element.

The run-time assessment mechanisms are based on the specification and quantification of design-time assumptions. During design-time an engineer has to answer questions like "which failure types are affecting the components and what is their impact?", "How are these failures detected and how good the detection mechanisms need to be?" and " How is the data conditioned and filtered to compensate the effects of failures?". Based on these assumptions the engineer adjusts the quality of the component's outgoing data at run-time to the integrity requirements. In our approach, these engineering assumptions are quantified to allow a comprehensible assessment. Assumptions are quantified in a failure model, a quantification of the detection capabilities and the filter characteristics. This is particularly needed when such a component is used in a larger setting or will be reused in another design. As an example we examine a typical component where the input data is provided by a sensor.

We distinguish two flows of information in Fig. 3. The lower part generates the nominal data output while the upper part is devoted to the calculation of the integrity attribute. In this paper we will focus on the definition and transformation of the parameters defining the integrity attribute.

We are considering a data centric failure model [START_REF] Ni | Sensor network data fault types[END_REF] which specifies failures in terms of how they affect the data e.g. according to an anticipated signal behaviour. The starting point is the identification of relevant sensor failures. Sensors deliver continuous values that may be affected by e.g. noise, offsets, spikes and outliers. A detailed discussion about sensor failure modes is given in [START_REF] Zug | Fault-Handling in Networked Sensor Systems[END_REF]. An assessment vector quantifies for each failure type a number that characterizes the anticipated severity and the occurrence probability of this failure. This is comparable to a risk priority number in the FMEA (Failure Mode and Effects Analysis) scheme [START_REF] Stamatis | Failure Mode and Effect Analysis: FMEA from Theory to Execution[END_REF]. Different from FMEA, we provide a scheme that allows combining multiple failure types and using this for run time assessment, while FMEA maps multiple failure types to the static worst case risk priority number. For describing the detector and filter characteristics we provide transformation matrices that modify the assessment vector for the respective stages. In case of a detector, the matrix specifies the ratio of correctly detected failures versus the wrongly and not detected failures. This statically sets the upper and lower bounds for the integrity attribute and modifies the assessment vector accordingly. The filter matrix defines the impact that the filter may have on the signal, i.e. the degree of suppressing a faulty signal. A filter that operates as a failure masking mechanism will raise the lower bound for the validity because it eliminates faulty values. Applied to the assessment vector it modifies the respective elements related to the affected failure types. The assessment vector finally holds for each failure type an element that describes which effect this specific failure will have on the final integrity attribute. It should be noted that this number includes the capabilities of the detector and filter with respect to the particular failure. The integration stage collapses the vector representation to a single scalar integrity attribute. This stage uses a selection vector that holds weights for each failure type and therefore allows a further restriction to relevant failure types. E.g. for long term navigation, single outliers of a localization sensor may not be as relevant as a constant offset failure. However, outliers may have a high impact on the validity because of their amplitude. Thus, an outlier would decrease the integrity attribute to an inacceptable low level although it would not be relevant. Another application may need a high validity of differential positions. Here, constant offsets would not play a major role. The selection vector can adjust these different application needs. In the end, we obtain what we call the system validity, a measure of how good the detection and filter mechanisms will deal with failures.

So far, all the information that is captured in the assessment vector, the transformation matrices and the selection vector is available at design time and quantifies of the engineering assumptions about relevant failure types, their impact, the quality of the detection mechanism and the power of the filter in suppressing the effect of failures.

In the conventional approach, the outcome of this analysis would be compared to a required integrity and in the case of a match, the design would be accepted. This implies that the assumptions about the failures, the detection and filter capabilities are worst-case assumptions and require a substantial amount of resources to keep the bounds. If the design does not fulfill the static worst-case requirements, the design needs to be changed. This may require substantial redundant resources or more expensive components even though the actual operation would not even come close to the worst-case bounds in by far the most cases. In the proposed architectural pattern, the numerical representation of the integrity is exploited to detect at run time whether the component will meet the integrity requirements. If the dynamically derived integrity attribute falls below a certain threshold, we are able provide the countermeasures on a higher level, i.e. on the level of provided services that may need to be degraded (see also the example in the next section B).

At run time, the detector will provide a result for each failure that it is able to detect. These outcomes are stored in a vector with the same dimension as the assessment vector. The elements of the assessment vector are applied as weights to this vector to form the validity vector. The validity vector represents the actual estimated validity as a result of the detector stage. It is transferred to the filter stage where a similar calculation is performed. The final validity vector holds a dynamic estimate about the validity of the generated nominal data item with respect to each failure type. Finally, this vector is converted into a single scalar number which represents the integrity attribute. The details of the assignment of values and the operations defined by the failure algebra are beyond the scope of this paper. They are provided in [START_REF] Brade | Validity-based failure algebra for distributed sensor systems[END_REF].

B. Relating the validity estimation to the Integrity Attributes

In a safety-critical system, the hazard analysis will result in a set of functional failures that should not occur. In the coming phases these restrictions are broken down to what failures should not occur for the elements in the chosen architecture. Still, all these failures are restricted by the safety integrity level attributes telling how sure one have to be that these failures will not occur. The question is how sure we can be at run-time about the absence of these failures, if we cannot guarantee at design-time that this will always hold. We now will show, how the dynamic validity can be exploited to quantify these requirements. Let us first use a simple data centric model of failure. Failures may be specified in terms of its amplitude, e.g. the error exceeds ±5% of the true value or in duration e.g. that they will not last for more than 10ms. According to the goal of our architectural pattern, we enable the dynamic change of the Level of Service (LoS) to maintain a required level of safety. For the information generated by a component that contributes to a function we need specifying The complex component provides a nominal output that is subject of multiple safety requirements ranging from the highest ASIL D to QM. Integrity attributes are provided at separate outputs. They are represented as an integrity attribute vector that holds for each failure the confidence that it does not exceed the predefined bounds. Considering the thresholds in Fig. 4b, we model failure classes that e.g. do not deviate more than ±2%, ±5%, ±10%, ±20% and ±30% from the true value for ASIL D, C, B, A, and QM respectively. The integrity attribute vector holds the respective confidence values that these values are indeed within the specified bounds. If the confidence drops below a certain value in the most demanding safety class, this confidence value may well be within the bounds of a lower one. This would be reflected by the integrity attribute of the respective failure class. In this case, that the integrity attribute is too low, it may be necessary to switch to another level of service.

The notion of validity that was introduced before can be mapped to this more safety centric perspective. Given that the requirements of the safety integrity level concerning the error of the nominal value are specified, the validity calculus allows defining the failure characteristics through the computational chain. The failure model will be adapted to the thresholds of the amplitudes. Consider that the failure may not exceed ±2% of the true value and we want to be sure about this at a certain confidence level. This affects the choice of the sensor, the detector and the filter. The validity calculus allows to quantify these effects. At the sensor, an assessment vector represents the sensor characteristics for each failure type in terms of amplitude and of occurrence probability. If the requirements specify a very low margin on the amplitude of failure, noise, small offsets and drift have to be considered. We have to consult the failure model to see which failures are effective in such tight bounds. This will be analysed statically for each deviation addressed in the example above. In the end, we will have the design-time assurance that at run-time, under all anticipated conditions, the output of the component will have the integrity level indicated in the respective integrity attribute vector. If the safety requirements are very high, as it is e.g. required for ASIL D, the quality of the sensor and the mechanisms to mask a failure to always be within the bounds must be very high. I.e. we may need massive redundancy of expensive components. The problem is, that even a less expensive sensor will deliver results within tight bounds most of the time with sufficient probability. Detection and filters will detect or suppress failures sufficiently most of the time with sufficient probability. Thus the probability of a failure at run time will meet the ASIL D requirements most of the time but violations may happen. Conventional systems usually do not use the mechanisms to assess the integrity level at runtime. Instead they guarantee by design time analysis that such violations will never happen.

In contrast, our system explores the safety-cost-performance trade-off by offering multiple levels of service. Without sacrificing safety, we may run a function with a lower integrity attribute at a lower level of service. Prerequisite for this is the run-time assessment. The run-time integrity attribute output will give us, for each of the bounds specified in the example above, the confidence that the actual nominal value really is within the respective bounds. Thus, the design-time analysis is the basis to derive the run time values. The quality of detection and filter mechanisms are included in this assessment. A detector, for example, is characterized by the probability to deliver false {positives, negatives} and true {positives, negatives}. It is clear that for guaranteeing a very high confidence in the checked data, these values must be adequate. An ideal detector with no false positives and negatives will detect each failure correctly and therefore will transform the integrity attribute of a nominal value to "0" in case of a failure detected and "1" if no failure is detected. Real detectors, of course, will have weaker bounds. For a filter we similarly specify the ability to mask a failure. Details of these calculations are presented in [START_REF] Brade | Validity-based failure algebra for distributed sensor systems[END_REF]. As a consequence of the quantitative representation of engineering assumptions and the tight interplay between design time assurance and run time assessment, we can adjust the needed confidence according to the needs of the safety requirements. If such a dynamic value, represented in the integrity attribute, is not sufficient for a function running in a certain assurance level we have to switch to a lower level of service.

VI. INSTANTIATION IN AUTOSAR

AUTOSAR is a de facto standard in the automotive domain enabling an integrated architecture. It defines how to specify application software components (SWC) that are reallocatable. All software component inputs and outputs are as data elements through ports. Our suggested pattern implies that each data element should consist of a duplet: the existing nominal data element, complemented by an ASIL attribute. It is the responsibility of each SWC to compute the corresponding ASIL values. If there is no redundancy implemented, this means that the input ASIL values are inherited for the output values. Otherwise, ASIL decomposition is applied according to the algebra as defined in the ISO26262 standard. We furthermore propose a new basic software module (BSW): Safety Manager. This is in line with existing managers among the BSWs today. This new safety manager will compare the computed ASIL value of each signal with the required ones, that are stored for each function level of performance/service. In AUTOSAR today, all data elements are already connected to the run-time environment (RTE), constituting the interface for the BSW. Our pattern hence implies that the RTE will be extended with the requirement to connect all ASIL values to the Safety Manager.

The concept of modes is on three hierarchical levels in AUTOSAR: Vehicle Modes, Application Modes and BSW Modes, see Fig. 5. It's only the BSW modes that are standardized in the AUTOSAR set of specifications. It is assumed that different applications have implemented modes in their definitions. The control of these modes is within the application implementation, i.e. it is implemented by application software components (not in the platform). On an even higher level than application modes, there is Vehicles modes, which are global for the entire vehicle. As seen in the Fig. 5 there might be influences between modes on all these levels. We assume that the existing concept of application modes can be used for forcing all applicable SWCs to a mode corresponding to the level of service/performance as considered the highest and still safe by the Safety Manager. This is one extra connection between a SWC and the RTE, but it is in-line with the existing pattern and hence considered as an attractive extension of AUTOSAR.

As we don't consider checking spatial and temporal interference between SWCs, the normal BSW mode managers as specified by the AUTOSAR standards such as: ECU State Manager, BSW Mode Manager, Communication Manager and Watchdog Manager are not of importance here. The application mode managers are implemented as ordinary software components and communicate with other software components via RTE.

VII. INSTANTIATION IN IMA

Currently, in the avionic domain IMA is considered to be implemented by means of the ARINC 653 specification [START_REF] Aeec | Avionics application software standard interface, part 1required services[END_REF], which determines that applications are functionally separated in logical containers, called partitions. One goal of partitioning is to ensure the containment of faults in the domain in which they occur. Partitioning in logical containers implies noninterference of applications' execution in the time domain and the usage of separated memory and input/output addressing spaces [START_REF] Rufino | Architecting robustness and timeliness in a new generation of aerospace systems[END_REF].

Application software components are hosted in partitions. All software components inputs and outputs are as data elements, using the inter-partition communication services provided by the ARINC 653 Application Executive (APEX) application programming interface primitives. In particular, we propose to take advantage of the sampling ports services to extend the software component port values with a DAL attribute, as illustrated in Fig. 6. The Safety Manager will also be hosted in a partition and it will monitor the DAL attributes of all software component signals [START_REF] Nóbrega Da Costa | Safety Kernel for Cooperative Sensor-Based Systems[END_REF]. This can be easily achieved by platform configuration, allowing inter-partition communication services to deliver the components' nominal output and DAL duplets both to the destination components and to the Safety Manager, which for will read the DAL attribute, as illustrated in Fig 6.

A similar approach can be followed when the Safety Manager needs to change the performance/service level and set a new application mode. This action, which may also take advantage of inter-partition communication services, is also illustrated in Fig. 6. The Safety Manager sets the highest possible safe level of service/performance and the components change to the corresponding mode.

Vehicle Modes BSW Modes Application Modes

With this approach the instantiation of the general architecture pattern in IMA/ARINC 653 platforms does not require any modification or extension of the platform itself; only a platform configuration action is needed.

VIII. CONCLUSION

This paper summarizes how to apply a new architectural pattern as an extension to existing state-of-practice in the domains of avionics (IMA) and of automotive (AUTOSAR). The pattern is applicable to solve the problem when it is hard to show in design-time that a high safety integrity is met under all circumstances and for 100% of the mission. By introducing different levels of service/performance each having different implications on needed safety integrity, high performance most of the time can be combined with guaranteed functional safety all of the time. The pattern constitutes that every signal value that is the candidate for different requirements on safety integrity levels, should be evaluated by a redundancy mechanism capable to calculate a run-time estimation of the actual provided safety integrity level. Furthermore, the pattern implies the introduction of a Safety manager taking care of checking the safety integrity level attribute of every system signal. The safety manager compares during run-time all currently provided safety integrity levels with those derived from the break-down of the hazard analyses of the different levels of performance/service of the vehicle functions. As a result of the comparison, the safety manager enforces all functions to operate in the highest performance/service level that is still safe, by means of application mode managers.

Fig. 1 .

 1 Fig. 1. The figure of a general architecture pattern. Each software component communicates via ports with signals. Each signal is a duplet with a nominal value (V) and a safety integrity level attribute (I). The safety manager checks all safety integrity level values, and decides what function modes that are safe. The mode manager tells each software component about the mode decisions

Fig. 2 .

 2 Fig. 2. Estimating the signal quality by a checking mechanism.

Fig. 3 .

 3 Fig. 3. Computational chain for a sensor processing component.

Fig. 5

 5 Fig. 5 How the different kinds of modes in AUTOSAR may influence each other.

Fig. 6

 6 Fig. 6 Instantiation in IMA/ARINC 653 platforms

This work was supported by the project KARYON (reference no.: 288195), funded by Seventh Framework Program (FP7/2007-2013) of the European Commission. Rolf Johansson and Kenneth Östberg are with SP Technical Research Institute of Sweden


Fabien Retho

Hichem Smaoui

Jean-Claude Vannier

Philippe Dessante

Model of Intention: A concept to support models building in a complex system design project

Introduction

A hybrid propulsion system for aircraft application represents a new paradigm for propulsion systems designers. Several new problems appear, and classical design methods must be challenged. Indeed, addition of new systems and new components inside the aircraft architecture imply the need for a multidisciplinary study, in order to support design and integration. For example, addition of a battery pack to a propulsion system requires functional analysis, performances estimation, energy management and operational strategies. More than these aspects, related to design, integration is also challenged: where to locate the battery pack, how to manage thermal effects, how to manage electromagnetic effects… To address these two parts, design and integration, early in the design, we propose to build a model of intention. This article is dedicated to the concept of model of intention in a complex system design project. This concept will be explained, justified, developed and tested in order to allow reader to have clear vision of what represents the model of intention.

The first part explains why model of intention has been proposed. This part starts from observation in design process, and proposes some ways to improve it, especially in term of model and simulation. A global process is described where model of intention has an important place. The second part proposes a zoom in model of intention process of global methodology. To support this theoretical description, two examples will be described, corresponding to two different cases of model of intention utilization. A third part proposes utilization of model of intention previously described. Opportunities, advantages or drawbacks are highlighted, completed by critics and improvement expected. A synthesis of global model of intention contribution is proposed as conclusion.

2. Model of intention in complex system design 2.1. Complex system design All along this paper, design work on hybrid propulsion system for a copter-based unmanned aerial vehicle (UAV) is applied to illustrate concepts. Hybrid term is used as Vehicle in which "propulsion energy is available from two or more kinds or types of energy stores, sources or converters, and at least one of them can deliver electrical energy." [2]. A complex system is defined by White as "An open system with continually cooperating and competing elements." [START_REF] White | On Principles of Complex Systems, Engineering Complex Systems Made Simple Tutorial[END_REF]. Hybrid propulsion system is clearly a complex system, with most interesting points are innovation, multidisciplinarity, interaction between environment and sub-systems, and potential interactions between sub-systems.

To design complex system, numerous methodologies exists, based on systems engineering practices, as presented in Beitz, INCOSE or NASA books [START_REF] Beitz | Engineering design: a systematic approach[END_REF][11] [START_REF]Systems Engineering Handbook[END_REF]. De Tenorio has proposed a collaborative methodology to support innovative multiphysic system design [START_REF] De Tenorio | Methods for collaborative conceptual design of aircraft power architectures[END_REF]. The collaboration aspects highlighted in his works shows mandatory collaboration process for design. Completed by design models and optimization, several architectures and design can be analyzed with his approach. Liscouët proposes a methodology for energy management inside aircraft [START_REF] Liscouët-Hanke | A model Based Methodology for Integrated Preliminary Sizing and Analysis of Aircraft Power System Architectures[END_REF]. This methodology proposes collaboration essentially around model. The sizing methodology is based on a two phases process, sizing and simulation. In the methodology proposed in this paper, only simulation is used to design. These two approaches are inspiriting the proposed methodology for model, simulation and collaboration, and initiate the interactions and model request formulation. In the field of interactions between systems in a model based approach, Paredis et al. proposed to link models with specific sub-models corresponding to potential interaction based on physics [START_REF] Paredis | Composable Models for Simulation-Based Design[END_REF]. This approach has motivated interaction analysis for complex system and for design phases. All the links proposed can have several granularities in order to accurately answer questions. The granularity decomposition is a main focus of Basset et al. methodology [START_REF] Basset | the Onera multi-level rotorcraft concepts evaluation tool : the foundations[END_REF]. This last approach focus on industrial collaboration for an aerospace multidisciplinary design based project, with models decomposed on multiple level of modeling. Price et al. proposed in that way an analysis of possible lack of granularity model under different domain [START_REF] Price | An integrated systems engineering approach to aircraft design[END_REF]. In comparison of all these works, the methodology proposed with this paper, and especially based on model of intention, tries to explore the relationship between design, models and simulations, with a focus on having the right model at the right design phase, using a collaboration process.

A numerous number of tools and associated methods exist already for model a system quickly, or completely. In one hand, system engineering design model are already used (SysML graphs, requirement management). On the other hand, and at the cross between systems analysis and physics, functional architecture modeler allows proposing more behavioral model, essentially often based on physics (modelica language, bond graph theory…). Out of these two aspects (pure system and system behavior), physics based with very specialized domain methods and tools are used for detailed design and integration (CFD…). The proposed methodology is based on Model Based System Engineering (MBSE), a domain that proposes a continuous model experience, from requirement to behavior. In that way, some solutions and methods are proposed, as example with Schamai and ModelicaML approach, which allows joining SysML with Modelica for requirements validation [START_REF] Schamai | Towards Unified System Modeling and Simulation with ModelicaML: Modeling of Executable Behavior Using Graphical Notations[END_REF]. Requirements-Functional-Logical-Physical approaches summarized the final field of the methodology proposed. This decomposition contains all different steps mandatory for a successful product design. In addition of collaboration, model request and multidisciplinary, the RFLP decomposition offers a right frame. Belloncle et al. proposed an example of use of RFLP, applied to their specific study-case [START_REF] Belloncle | An Integrated Approach to Developing Automotive Climate Control Systems[END_REF]. For the methodology proposed, RFLP is applied not as a process, but horizontally, in order to ensure that all different specificities of each term are confirmed. If a Requirement, that has allow developing Functional and Logical architecture is correct virtually, in design and integration (physical), it is correct to affirm that system is properly designed. In that way, the methodology proposed wants to challenge the link between, on one side pure design problem (requirements, functions) and on other side behavior on simulations (environment, sizing and integration). In that way, hypothesis has been selected to build a methodology:  Base analysis on a Scenario: Notion of view, architect's questions and modeling strategy  Base system design on Systems Engineering : MBSE extension with interactions analysis  Develop virtual solution(s): Models and simulation for a simulator to design product.  Enhance collaboration: Experts and system designer have not similar and global skills. With collaboration, it is possible to combine all aspects.  Analyze interaction between systems: A choice to drive methodology, an access point to merge system and physical world.

To manage models and simulations, a role is introduced with simulation architect, the builder of model of intention. Simulation architect is represented as an alone person for theory, but he is destined to be a team. In order to support model and simulation for architect, and create a link between design and integration, model of intention is a concept proposed for simulation architect to manage models request.

Model of intention

Model of intention only concerns behavioral and environmental models. The necessity of model of intention comes from the will to transit from pure system models world to physical world. A question is, how to be able to request right model to an expert that has appropriate skills. In fact, model of intention is an alternative way to specify a model.

One of the major advantages of using a model of intention as a model specification is the bi directional benefices; for architects, that obtains a model to answer his question; for experts, that can propose advices of technologies via a model, with more freedom than a strong and inflexible specification contract. Another important point for model of intention is the simulation capability. To join the idea of offer more freedom to expert, model of intention can be run to analyze system under design. According to the study-case, a parametric model, based on power vs. mass, is proposed to represent functional/logical architectures. For the study-case, the model has been developed in Modelica, with OpenModelica tool [START_REF] Openmodelica | [END_REF]. This model, base for future model(s) of intention, includes some requirements (linked with power and mass) and includes a parametric mission block (Figure 1). All components, or blocks, that composed the model have exchange ports, and contain "simple" relations that define a behavior (factor, empiric results, table…). As example, electric motor is composed of 3 major parameters (Power density (Watt/Kg) and mass (Kg) to define max deliverable power of motor; Efficiency (%) that allow to determine real power delivered) and 4 ports (Power delivered (W); Power required (W); Mass (kg); Requirements (Boolean)). The methodology proposed is global, from a functional/logical architecture and top level requirements (TLR) to a virtual solution. As mentioned previously, scenario, based on an architect question is a mandatory step in the methodology. The heart of the approach is the interaction and impact analysis. It is the real bridge between world, because allows to inject physics into systems and conversely. In that way, the methodology is inspired by RFLP. It is proposed to flatten the RFLP sequencing, and consider more specifically a Requirement-Functional-Operational-Physical decomposition (RFOP). The L-Logical is not considered for the moment excepted inside architecture input. The O-Operational is added in order to consider mission and mode (for energy management), mandatory in a simulation process. The RFOP represents in fact different views to characterize systems. Added with interaction (I), FOP-RI decomposition is proposed.

A Three steps methodology

The methodology has three blocks. The first block, named system, is proposed with system engineering models. This step associates requirement, functions and system to attributes. An attribute is a characteristic of a system. An attribute is associated to a discipline, a domain which allows it to be filtered in views. Attribute is the base for interaction detection. The second block is interaction one. An attribute can have two different functions: it can be a requirement (R -if a requirement is associated), it can be an impact source (I -Scenario) or both. The process of interaction detection is to link an impact source to a requirement following an interaction matrix. With this approach, it is possible to visualize directly first order impact of the characteristic of a system to another one. This concept of R-I is important to understand model of intention building.

The last block is M&S. This block contains model of intention as a link to follow to virtual solution and simulations. In that block, all analysis are used to support simulator building, used to follow scenario, and so the architect's question. The collaboration between simulation architect and expert is done around a model of intention and model of realization. When model of realization is accepted to satisfy scenario needs, integration in simulation chain and simulation runs can be done. Results obtained are selected then to satisfy scenario. If model of realization is accepted, but cannot answers scenario, there is a deeper problem, directly in link with scenario (first check) or with interactions analysis (second check). The model of intention building is a sub-process that implies some notions of ports, behavior and simulation. As previously mentioned, model of intention, as defined with proposed methodology, is composed of two distinguished parts, a document and a simulatable model. Model of intention is also a platform to exchange with experts: It contains requirements, architecture information, design hypothesis, and pre-design solution(s). In that way, it is an interface, initialized by simulation architect with interactions and impacts analysis. The sub-process proposed in Figure 3 described the model of intention block of global methodology (Figure 2). This process is separated in 2 major tasks corresponding to the 2 faces of model of intention full package: document and model phases. Interactions and impacts study is an input for model of intention. Model of realization is the output and is done by experts after they received the Full package. The accept model question represents dialog that must be done between simulation architect(s) and expert(s). At the end of the dialog, if model cannot be accepted, it is mandatory to determine where model of intention has to be updated. Of course, if model is accepted, process continues to model integration and simulations for virtual product consolidation. The final aim is to offer a robust model of intention to reduce at maximum misunderstanding and dialog loop.

Model of intention building process

Document generation and validation

The document is a part of model of intention. Full model collaboration hypothesis is for the moment, impossible. Another point, justifying a document, is advantages of having a trace of work. An improvement expected of the methodology is to be able to construct automatically this document in parallel of methodology application. As a template, 4 parts are proposed:  Scenario: Contains question, mission, functional/logical architecture and hypothesis;  I&I: Contains attributes, interactions detail and physics/behavior expected;  M&S request: Contains model of intention explications, ports considered, behavior and hypothesis on model requested and models to be updated.  Annexes: Information on previous design, previous virtual model, detail on geometry and all other useful information for model parameters and setting.

It is important to note that this document is oriented to support simulation architect works. Each part can be modified or removed to adapt the document to the contact. Contact can be system architects, system experts, domain experts, subcontractors or partners.

Model phase 1:Blank model

The model phase 1 derives directly of interactions and impacts analysis. As explains, interactions and impacts are based on attributes, kind of systems/subsystems characteristics that influence design, and so freedom of designers. The objective of that phase 1 is to be able to propose a blank model, i.e. a model of intention without any behavior, equations and physics. A blank model is just composed of:

 Inputs: What information we can bring to the future model of realization;  Outputs: What information we want to be generated/calculated/estimated by the future model of realization.

A blank model has different type of ports that are defined to represent different type of information that ports deliver (flow, field, discrete values…). For the moment, 6 types have been defined. Work is in progress to adjust ports types for better model definition. The model of intention port attribution is defined with interactions and impacts analysis. To stick with attributes proposed for interactions and impacts, each port is associated to an attribute. This important point permits smooth transition in all methodology steps. The hybrid propulsion system study-case is proposed with a model under Modelica language (Figure 1). Phase 1 is the integration of a blank model with right ports inside the global model (power vs. mass). Integration implies additional port addition, or creation of a new system block. Port type allows also detecting where information must be taken, in term of other system block model. In that way, it is important to add some new port to other systems implies in scenario and where interaction and impact has detect a need. An example of blank model of intention is proposed in Figure 4.

Model phase 2: Simulatable

The concept of "simulatable" model of intention is a pillar in model of intention concept. However, if a model is simulatable, it means that a behavior, as simple as possible, is including inside a model. The model power vs. mass, introduced in Figure 1, is composed of blocks. Each block is associated to a real system, and each block is a part of a simulation chain. If a block is deleted, simulations capability of the global model is compromised. So, if designers need to introduce new system, or want to add or refine a model, behavior must be taken into account to ensure simulation capability. Simulation architect is not an expert in domain, physics or particular system. In that way, it is quasi-impossible for him/her to propose a behavioral model. However, he/she can work with existing material just developed in previous steps of model of intention process.

Ports of model of intention, that represent information, have been defined. The objective is to be able to switch a blank model of intention to a simulatable one. To perform that switch action, it is necessary to link inputs to outputs. As mentioned previously, non-expertise does not allow simulation architect to build final model (i.e. model of realization). Several options have been highlighted to support simulation architect in its model of intention simulation capability addition:  Factor: A simple relation with a factor can be proposed. As example, efficiency or a density can permit to link an input with an output. Value or range of potential value of this factor is then a hypothesis that must be challenged.  Empiric results/tables: For a set of input, literature, experiences or tests can support construction of a table that delivers a set of output.

Whatever the solution for simulation capability chosen, model of intention must appear as clear as possible in term of hypothesis, in order that experts understand clearly what simulation architect has done. Simulation capability is a feature that requires being rigorous to avoid misunderstanding.

Model of intention parameters setting and full package

The last step in model of intention sub-process is the delivering of a full package to expert. Just before validation of full package, it is mandatory to set all parameters of model of intention. This step is important because expresses requirements, hypothesis and previous direction given to the design.

Since parameter setting is done, and document is validated, the full package can be transferred to expert as a specification for model of realization. It is important to remember that even if model of intention building is a large process, it represents only a platform that must be challenged by each parts, simulation architect and experts. Finally, model of intention is just the translation of an architect question to model and simulation world, supported by a scenario.

Hybrid propulsion system study case

First Application

Hybrid propulsion system for aeronautic is an innovative propulsion system solution. The studycase, presented in Figure 1, proposes a hybrid parallel architecture and a sizing mission. The model proposed corresponds to a base for model of intention, but can support first pre-design questions: Is it possible to perform the mission with a hybrid parallel solution, or, what is the best endurance possible, or what is the best payload to carry? These questions have been merged to propose to estimate endurance vs. payload with the power vs. mass model.

In order to answer this very first question, that could be fatal for the project, an optimization process based on evolutionary algorithm (NSGA2 [START_REF] Deb | A Fast Elitist Non-Dominated Sorting Genetic Al-gorithm for Multi-Objective Optimization : NSGA-II[END_REF]), and 2 objectives is proposed. 8 optimization variables are selected. A Pareto front is obtained, and mass decomposition of architecture is estimated, considering some strong hypothesis that must be challenged with an expert eye.

Questions from architect

In order to illustrate the model of intention building, hybrid propulsion system design and integration, on the copter-based UAV, is challenged around two questions that represent two different types of model of intention:

 Question 1: Mass of batteries is a critical issue for UAV design. Is it possible to reduce uncertainties on battery mass estimation?

 Question 2: Thermal environment inside UAV is a critical issue. Is it possible to have an estimation of sub-systems temperatures during a mission?

The question 1 expresses the request of a model refinement, and a closer link with technologies. The objective is to obtain a model of realization that considers more accurately the link between mass of batteries and technologies or products-on-the-shelf. With the future model of realization, architect will have information (results of simulations) to estimate mass of batteries needed versus technology.

The question 2 expresses the request of new discipline consideration, thermal transfers. This discipline, mandatory to consider integration, provokes a lot of potential interactions that should be quantified. A new model is also necessary, the fuselage model which will integrate thermal behavior models, and support sub-systems temperature evaluation.

The objective of that demonstration is trying to detect and quantify where the model of intention sub-process can be generalized (Figure 3). For each scenario, works on system and interactions blocks of global methodology (Figure 2) are not presented in this paper due to the focus on model of intention.

Scenario 1: Batteries mass

This scenario represents an improvement of model prediction and behavior. The model for battery inside power vs. mass model considers technologies of battery only through 3 parameters: energy density (Wh/kg), time constant for charge (1/h) and for discharge (1/h). This model considers that mission is not satisfied when battery is empty although it is mandatory that it delivers energy. Since this instant, mission is compromised and the mass of battery (parameter) is not sufficient. Future model of realization must keep this approach, with a real link with technology.

Interactions and impact process is not useful for model of intention building for this scenario, just because model inside power vs. mass model is the real model of intention. This is due to the fact that no additional port has been detected, and behavior is already inside. The parameter setting phase is already done with the first pre-design work presented in previous part. To complete a full package, document is built (not automatically for the moment). The full package is ready to be sent to expert.

The model of intention for scenario 1 was quiet easy to build, and illustrate the necessary work to create a global model for model of intention basement. For the hybrid propulsion system, or other energy analysis in aeronautic, mass and power model seems to be the simplest, quickest and more interesting model to develop initially.

Scenario 2: Thermal environment

This scenario represents close link between design and integration. The model requested is an environment model that allows estimating quickly temperature of sub-systems inside fuselage, in order to avoid sub-systems critical temperatures. In current power vs. mass model, there are no thermal effects considered. Interaction and impacts analysis, with a thermal filter/view, is mandatory for simulation architect to be able to propose a model of intention.

The scenario defined considers only 4 sub-systems that have a potential thermal influence. These sub-systems are Fuselage, Electric motor, ICE (Internal Combustion Engine) and Battery. Simulation architect has considered fuselage model has a host for thermal environment inside UAV model. Interactions and impacts are based on the fuselage and authorize to impact, or be impacted, by three other systems. The blank fuselage model of intention is built following results of Interactions and impacts analysis (Figure 6). Several attributes are highlighted as input or output, with different type. Each type will not be detailed in this paper. However, it is interesting to note last column of Figure 6 table, which shows the necessity of update other systems model in addition of fuselage model. The phase 1 of model of intention is finally completed with addition of new port, and fuselage model, directly inside an alternative version (V2) of power vs. mass model.

The model phase 2, behavior addition, implies 4 system models. Simulation architect has considered as input the heat power attribute. This attribute is, by hypothesis, amount of power that is not directly used by a component (power lost). With efficiency, it is simple to consider a heat power. For the fuselage model, which represents a sort of hub for heat powers, it is impossible to extract a simple, or empiric, relation to determine all temperatures without entering inside a domain expert field. However, temperatures do not interfere with simulatability capability of model of intention because temperature values are not directly used inside the simulation chain, there are only observables.

The parameter setting phase is tricky, due to the possible lack of information on any parameters. Parameters linked with shape, which are basic form (cylinder, block…) and size, of each sub-system is not clearly set at this point of design. In that way, any hypotheses are done to allow simulations. Hypothesis is closer than possible of reality, but offer uncertainty risk for simulation results. As it will be explained later in this paper, hypotheses are clearly dangerous for designers and decisions they have to take.

In parallel of the elaboration of blank and simulatable model of intention, and even before with the Interactions and impacts analysis, the document was completed in order to be able to propose a full packaged model of intention. After analysis of model of intention scenario (document), it appears that the will is to propose a model that takes account of technologies parameters to size battery mass, to challenge hypothesis of model of intention (i.e. energy density, rate of charge and discharge). Expert has selected two batteries previously used in other project (battery A and B). He has selected these solutions because he has understand the need in this project, thanks to several simulations that has allowed him to detect maximal power and amount of energy desired. This point is interesting because it illustrates the freedom offer to expert to push some solutions more than other. Of course, in this simple case, no money or business problems interfere in confidence offer to expert by architect and simulation architect.

The model of realization is the vector to transmit expert's advices and pre-choices. In this case, expert has proposed a unique model, parametrizable to switch from one solution to another. The model is developed directly in Modelica, in order to avoid integration problems which are out of scope of model of intention.

Figure 7: Model of realization contains solutions parameters

As a simulation architect to architect collaboration, model has been simulated. Due to the out of scope for this paper of decision aiding for architect, only a simple comparison on different models results, on a similar mission and for same battery mass, is proposed in Figure 8. Model of realization results highlight that model of intention hypothesis on battery are optimistic, because battery discharge is lower than with real solution. As a decision aiding, without optimization for the moment, technology B seems to be more interesting. However, simulation architect delivers these results, architect acts decision. For the necessity of this simple use-case, a member of propulsion team has played this role. After having received model of intention, he proposes a manner to model a solution. A Model based on thermal node is proposed. This approach delivers results expected, i.e. temperature of sub-systems considered (ICE, Electric motor and Battery). All information necessary for this model is inside the model of intention. As the model requested concerns environment (physics), the expert has not proposed different model of solution. Expert could however propose different manner of modeling. In the current study-case, a unique model of realization is delivered. Another important point is the necessity highlighted, in Interactions and impacts phase, of having heat power of the others considered systems. For the study-case, models of considered systems have been updated to propose an output port that delivers the heat power information and surface wetted (Figure 6). The heat power is directly calculated with efficiency parameter (hypothesis of power loss of a system is lost as thermal). The surface wetted is based on volume (energy/power density) and basic form.

Advantages and drawbacks

Several advantages and drawbacks have been identified (Figure 10). Any of them can be turned into next improvement or research fields (especially tools limitations).

Actors + -

Figure 1 :

 1 Figure 1: Inputs and Power vs. Mass model After an analysis of the role wanted to be set to model of intention, we propose a definition: "Model of intention is a model based approach to request and specifies model(s) or simulation(s) for a specific scenario. Model of intention allows expert to propose adequate model(s), and to propose advices, technologies or technical solutions." 2.3. Methodology

3. 1 .

 1 Specific methodology for model of intention building 3.1.1. Overview

Figure 3 :

 3 Figure 3: Model of intention sub-process (extension of Figure 2)

Figure 4 :

 4 Figure 4: A blank model of intention with different port type (color) associated to attributes (name)

Figure 5 :

 5 Figure 5: Endurance vs. Payload with power vs. mass model

Figure 6 :

 6 Figure 6: Phase 1: Port addition to system models (red port  temperature; light green  shape)

4 .

 4 Model of intention : a practical example 4.1. Scenario 1 and 2 model of intention collaboration 4.1.1. Scenario 1: Collaboration with battery system expert This part relates a role play organized around model of intention full package corresponding to scenario 1, on uncertainty reduction for mass battery. The full package has been transferred to a battery system expert of a propulsion research team. This expert will try to satisfy the model request with the model of realization. At this point of methodology, collaboration is crucial between simulation architect and expert.

Figure 8 :

 8 Figure 8: Comparison of simulation results on a similar mission and for same battery mass 4.1.2. Scenario 2: Collaboration with thermal domain expert As for model of intention for scenario 1, an expert in thermal domain received the full package.For the necessity of this simple use-case, a member of propulsion team has played this role. After having received model of intention, he proposes a manner to model a solution. A Model based on thermal node is proposed. This approach delivers results expected, i.e. temperature of sub-systems considered (ICE, Electric motor and Battery). All information necessary for this model is inside the model of intention. As the model requested concerns environment (physics), the expert has not proposed different model of solution. Expert could however propose different manner of modeling. In the current study-case, a unique model of realization is delivered. Another important point is the necessity highlighted, in Interactions and impacts phase, of having heat power of the others considered systems. For the study-case, models of considered systems have been updated to propose an output port that delivers the heat power information and surface wetted (Figure6). The heat power is directly calculated with efficiency parameter (hypothesis of power loss of a system is lost as thermal). The surface wetted is based on volume (energy/power density) and basic form.

Figure 9 :

 9 Figure 9: Model of realization parameters

Conclusion

The objective of model of intention is to facilitate the use of models for design and integration decision on a product project. Hidden behind this idea, there is a will to extract model from expert, more than current tendencies consisting in pushing models by expert. Model of intention is simply a concept to support model specification, in order to improve collaboration in a way to enhance innovation and creativity. Even if the architect is the project leader and decision maker, initiatives can also be provided from expert, and models allow them to express their ideas. Simulation architect with his virtual or Model and simulation vision is an interface to allow the model-based dialog. To summarize, model of intention is a bridge, a tool for simulation architect, to create collaboration in a virtual world, and to continue to innovate, to design and to integer a real product.

Numerous challenges are yet to manage, especially in a proper and generic definition of a model of intention. A setting up of proposed methodology in a real industrial context shall be explored. The link between design models of system engineering and real physical world, environment, design and integration seems to be mandatory in order to break conventional design method and open larger innovation and creativity in future product.


Lucia Sanz

Andra Tonie

Christel Seguin

Rémi Delmas

Pierre Bieber

Patrick Fabiani

Model Based Risk Assessment of Procedures and Systems for Aircraft Trajectory Management

Keywords: Safety assessment, Air Traffic Management, I

Modern Air Traffic Management (ATM) concepts of operation require a strong interaction between agents such as human operators (pilots, air traffic controllers) and information technology systems (either on-ground or on-board). Although risks shall jointly be managed by all these agents, current risk assessment techniques are usually dedicated to only one class of agents (either human operators or IT systems). This paper addresses this issue. It proposes to extend Model Based Safety

Assessment (MBSA) techniques originally developed to assess complex systems. This MBSA extension enables to assess how risk can be jointly managed by procedures and systems. The paper shows the methodology used and it presents lessons learnt from an aircraft trajectory management case study.

INTRODUCTION

Modern Air Traffic Management (ATM) concepts of operation such as the one developed within the SESAR programme [START_REF]SESAR[END_REF] require a strong interaction between agents such as human operators (pilots, air traffic controllers) and information technology systems (either on-ground or onboard).

Although risks shall jointly be managed by all these agents, current risk assessment techniques are usually dedicated to only one class of agents (either human operators or IT systems). This paper addresses this issue. It proposes to extend Model Based Safety Assessment (MBSA) techniques originally developed to assess complex systems. This MBSA extension enables to assess how risk can be jointly managed by procedures and systems.

The paper shows the methodology used and it presents lessons learnt from an aircraft trajectory management case study.

II. TRAJECTORY MANAGEMENT

The management rules of aircraft trajectories are specified in ICAO's Annex 2 -Rules of the Air [START_REF]ICAO Annex 2 -Rules of the Air[END_REF]. We focus on the collision avoidance procedure applicable in the following case.

Collision avoidance involves two aircrafts: one aircraft and another one that we will call the intruder aircraft. Both are in cruise phase and are converging approximately at the same flight level. The aircraft is flying in one sector, and it is flying in radar controlled airspace in instrumental flight conditions.

According to ICAO specifications, the main actors of the Trajectory Management system of this scenario are :

• Pilot: In clear airspace the pilot can visually detect the appearance of an intruder; if this happens, the pilot shall ask the ATC for a route change. • Air Traffic Controller(ATC): If the airspace is not clear, or due to workload, the pilot cannot visually detect the intruder then the ATC in charge of that airspace sector shall inform the pilot and assist him during all the avoidance operation. The controller has access to some control panels where the radar tracking (ATCRBS -ATC Radar Beacon System) can be visualized, as well as VHF radios for oral communications and ADS (Automatic Dependent Surveillance) data-link communications.

• Traffic Collision Avoidance System (TCAS) [6]: If

both the pilot and the ATC fail in a prompt detection of the intruder, the TCAS equipment shall first announce the appearance of the intruder. It shall also provide the pilot with traffic advisories (TA) and resolution advisories (RA) depending of the distance between the two aircraft. When the RA is issued, the controller is no longer responsible for the separation of the aircraft until the conflict is terminated. Experience returns have proven the robustness of this procedure. However, incidents highlighted also its limits especially when equipment failures are combined with human inadequate performances. So we propose to conduct an integrated safety assessment of all the actors (human and equipments) to deal with such issues.

III. PROPOSED SAFETY ASSESSMENT PROCESS

The goal of safety assessment is to determine that every possible hazards (failure conditions) of a system were considered and that they were properly addressed. The first step of the safety assessment is the identification of failure conditions of interest and their classification according to their severity (ranging from Minor to Catastrophic). In this paper we focus on one catastrophic failure condition: aircraft collision due to total loss of conflict detection means. Quantitative and qualitative safety requirements are associated with the failure condition. For a Catastrophic failure condition, we consider the following qualitative requirement: "no combination of strictly less than 3 failures shall lead to the failure condition".

The system safety assessment examines the proposed architecture to determine how failures can cause the identified failure conditions. This assessment aims at showing that the qualitative and quantitative requirements are satisfied. Moreover, in case of aircraft systems, this assessment also establishes new safety requirements such as requested independence between component failures and requested minimal Development Assurance Level (DAL). We propose to apply the same principles to all the actors of the trajectory management systems.

We have used two different tools to assess the safety of the trajectory management:

• Cecilia-OCAS workbench from Dassault Aviation was used to model in AltaRica [START_REF]The AltaRica Formalism for Describing Concurrent Systems[END_REF] trajectory management and to study sequences of events leading to the catastrophic failure condition. • DALculator tool [START_REF] Bieber | DALculus -Theory and Tool for Development Assurance Level Allocation in Safecomp proceedings[END_REF] was used to generate independence, resource allocation and DAL requirements.

Usually these tools are used to model and analyse technical systems [START_REF] Bieber | Safety Analysis of the Systems Embedded with AltaRica[END_REF] and not human actors such as the aircraft crew or the air traffic controllers. The functioning modes of the technical systems of our simplified case study are modelled by a boolean variable ok that is true when the system is working correctly and its results are reliable and false otherwise. We have extended the modelling approach to deal with human actor failures. Since in trajectory management the main role of human actors is to detect the intruder aircraft we have introduced modes that degrade their capability to correctly detect the intruder

• in mode ok, the actor correctly detects the intruder.

• in mode positive, the actor always believes that there is an intruder, even if there is not. • in mode negative , the actor always believes there is not an intruder, even when there is. • in mode lost, the actor believes are undefined

The model describes all the actors of the trajectory management scenario and their interaction. The model also includes an aircraft node that observes all the actions that could take place and lead to a collision. This node is used to generate automatically the sequences of failure events that lead to a collision.

IV. RESULTS OF THE RISK ASSESSMENT

To analyse the model, we first used the Sequence Generation of the Cecilia tool. We found 34 sequences of events leading to the total loss on the conflict detection means. We used these sequences in the following ways.

First, these sequences were used to check qualitative requirements. Two sequences of size equal to 2 contradict the qualitative requirements: {copilot_detection.fail_loss, pilot_detection.fail_loss}, { ACFT.TCAS_fail, ATC_detection.fail_negative} However, the tolerance to two faults is a requirement justified by good practices of technical system design. Here, only the behaviour of the pilot, the co-pilot and controller play an important role that leads to a collision risk in these sequences. Indeed, only "single fault tolerance" is mandatory for the whole aircraft operation. Moreover, if fault tolerance issues can be solved by adding redundant equipments in the aircraft or in ground ATC station, we cannot easily have three pilots on board or two controllers working in the same stand. In conclusion, we made an exception and continued the analysis.

Then the sequences were used to generate independence requirements. The rationale is the following. If we want to ensure that no single/double failure leads to a catastrophic failure, we shall also require that events which occur in sequences of size 2/3 are independent two by two. In our model, there are several sequences of order 3. According to this, their segregation was not studied by hand but with the help of the tool DALculator.

DALculator proposed to require the independency of the items given in the table below. Independency implementation requires diversification of components. The table discusses also the diversification issues in our study case.

Independent components Why can they be independent? pilot_detection copilot_detection

Commonly is said that "there are not two people alike". Pilot and co-pilot are independent because their decisions come from their inner professional criteria.

ATC_detection TCAS

The most obvious of the independences is between the different technologies human and systems are made of.

processing_equipment_1 processing_equipment_2

The independence between these two items may be the most difficult to achieve, two processing equipment with different software are needed.

processing_equipment_3 TCAS

As these two components have very different functions, they do not share common software computation. signal_comparator_1

Idem to the explanation above TCAS for the processing equipment and the TCAS.

Table 1. Item Development Independence.

Independency implementation also requires installing the items in different zones. DALculator tool also established the minimum physical zones where the components can be located. In our case at least two zones per group of components is needed:

• Crew on board: pilot and co-pilot have different positions in the cockpit, with independent displays and flight controls; however it is impossible to place them in different zones of the aircraft, both of them need to be in the cockpit. Once again in this paper, we can highlight the differences between systems and humans. While a leakage of a pipe ("system_failure") can lead to a catastrophic failure if it is over navigation wires; if the pilot cries ("pilot_belief=undefined"), the co-pilot will not be affected ("copilot_belief=ok"), maybe distracted and stressed, but capable to do his functions.

• Controllers on ground: Their allocation behaviour is similar to the pilot and co-pilot situation. Various controllers share air traffic control centre but have separate stands, equipment and moods. • Systems on board: In this case study we only considered as on board equipment the TCAS and the VHF components. The results from the DALculator mean that the TCAS has to be allocated in a different place than processing equipment and the signal comparators of the ATC radar. This is accomplished by the fact that all these components are on ground while the aircraft is cruising. According to the VHF system, results about the on board radio are not found with DALculator because they do not even appear in the Minimal Cut Sets done for order 6 with Cecilia tool, which means that these components are not critical and their malfunction does not lead to a real collision risk. • Systems on ground: we considered two big groups of systems: controller VHF radio and controller radar.

Neither the controller's radio nor some sub-systems of the radar (ATCBRS transponders and control panel displays) affect catastrophically in the scenario presented; but for the other radar's sub-systems: one of the processing equipment shall be mounted apart from the others. The signal comparators can be in the same zone, as their function is just check the processing equipment results.

Finally, after identifying feasible independence requirements, we used the generated sequences to perform the DAL allocation with the DALculator. The Development Assurance Level (DAL) classifies the level of development of the equipment in order to prevent or eliminate design errors with more or less care. Depending of the level of severity of the failure conditions, a different DAL will be required. As we are working with a model for catastrophic failure, the overall conflict detection function shall have a functional DAL (F-DAL) A. However, the DAL of the system items (I-DAL) can be lower. New DAL allocation rules introduced in ARP4754A allow downgrading some components that appear in the minimal cut sets. This downgrade is possible for independent components and considering that the local degradation of the DAL will not lead to a safety problem. The interest of downgrading some of the components is due to the inverse relation between severity level and development costs: as higher is the severity level, higher is the cost; so with the DAL study the purpose is to have a trade-off between these two agents.

With DALculator the downgrade DAL can be obtained following two different approaches, both certified by international Authorities, so both valid. The final election between which one to choose will be made in order to optimize the development costs while preserving the feasibility. For instance, some too complex software cannot be currently certified at level A.

Several allocations have been generated. A first DAL allocation was computed by selecting "Option 1" solver and constraining the TCAS to a DAL equal to C (its current usual DAL). This makes some other components to become class A.

In particular for the co-pilot and the controller what this solution means is that, they have to be very reliable, so when they are needed, they are fully capable to avoid the intruder. The dependability on them also concerns their availability and continuity at work. In terms of safety, it is not interesting to workload the crew; however there is a positive point, there is not an increment of the development cost. .

A second proposed "Option 1" allocation sets TCAS to DAL A. In this case, most of the components can be downgraded to DAL C. We also can observe that the crew on board and the controllers on ground are less needed, as they dependability decreases. Only the co-pilot has DAL A classification, he/she represents the last chance for visual detection.

The tool shown also that "Option 2" is not feasible when TCAS DAL=C. "Option 2" when TCAS DAL=A is feasible.

There is only one item with DAL A, the controller, as it is a human resource he/she is not an additional cost.

Finally we did also the analysis for the combination of the two options and with the TCAS set to A. We got the following results:

DAL Component A TCAS B pilot_detection copilot_detection C ATC_detection coATC_detection processing_equipment_1 processing_equipment_2 processing_equipment_3 signal_comparator_1 signal_ comparator_2 D
The remaining components of the system. This last result seems optimal. However, it requires developing TCAS at DAL A..

V. LESSONS LEARNT

One challenges of this work was to model the faulty behaviour of human actors and their interactions with the systems. We modelled the scenario for collision avoidance established by ICAO's Rules of the Air in the AltaRica language. Another issue was to also to define requirements applicable to all actors of the system. We proposed to apply the approach defined for complex aircraft systems in ARP 4754 and we discussed the interpretation of fault tolerance, independence and DAL requirements in the integrated analysis.

The safety analysis allowed determining the principal differences between the components and the human actors involved in the collision avoidance procedure. These differences are:

• Redundancy: In order to make more robust the procedure, we can have redundant equipment, but we cannot have a higher crew redundancy. We have to trust that the only two available pilots and the controller are able to do their work correctly.

• Independence: The independence for components and human actors was studied with the same tool (DALculator), but the results have to be interpreted differently. Independence between two components means to have different development technologies between them to assure that the output data is reliable. While, independence between members of the crew is assured because it is intrinsic to human's nature.

• Zonal allocation: To determine the relative physical allocation of the items we also used DALculator tool. The allocation constraints are essential to place correctly the redundant and independent equipment; in order to avoid that a single failure is transmitted to other essential equipment for the avoidance.

• DAL allocation. Currently highly qualified human actors are requested to recover lower DAL of TCAS. If TCAS can be qualified at a higher level, the balance could be fruitfully re-equilibrated.

Finally, it can be considered that this study -that models the nowadays collision avoidance procedure -propose a framework which can be applied for the analysis of the next concept for collision avoiding, defined by the SESAR programme.