WO2017056117A1

WO2017056117A1 - A method for determining the responsibilities in case of malfunctioning of an automated system for air traffic

Info

Publication number: WO2017056117A1
Application number: PCT/IT2015/000243
Authority: WO
Inventors: Patrizia MARTI; Paola LANZI; Giovanni SARTOR; Giuseppe CONTISSA; Hanna SCHEBESTA
Original assignee: Deep Blue S.R.L.
Priority date: 2015-09-29
Filing date: 2015-09-29
Publication date: 2017-04-06

Abstract

The present invention concerns a method for determining the percentage of responsibility of a subject, in case of malfunctioning of an apparatus, preferably an aircraft. The method foreseeing the phases of: Insertion, in electronic format in an electronic processor (1), of one or more apparatus__data comprising information relative to the apparatus and/or the subjects involved in the design/use/maintenance of such an apparatus; Determination of a level of automation of the apparatus through a comparison in the electronic processor between at least a part of the apparatus_data previously inserted and one or more similar apparatuses; Extrapolation, in electronic format, of one or more Obligations_of_Action which are the basis of the level of automation determined; Visualization by the electronic processor of one or more responsibility_maps relative to at least the subjects involved in the design/use/maintenance of such an apparatus; - Said maps being browsable by the user in such a way that the user can select one or more paths on the basis of the Obligations_of_Action determined for the malfunctioning in analysis, for each path corresponding a percentage of responsibility.

Description

TITLE

A METHOD FOR DETKBMININO TBS RSSP0NSIBILXTX8S IN CASS OF MALVrntCTlOMlMO OF AN AUTOMATED SYSTEM FOR AIR TRAFFIC Technical field

The present invention concerns the technical field relative to aircraft safety.

In particular, the invention refers to an innovative method for determining eventual responsibilities in case of malfunctioning of automated and non-automated systems, installed on such aircrafts.

Background art

It is known that aircrafts, both civil and military ones, contain multiple flight devices, many of which automated at least in part.

Some are in design and test phase and therefore, in fact, are not operative and not yet installed on the aircrafts .

Others, instead, have been installed and have been operative for some time.

For instance, the automatic piloting system is a flight system that has been known for some time. After the insertion of a route by the pilots, it is capable of taking the aircraft to destination even landing and taking off in an automated manner. In this case, the direct intervention of the pilot is obviously required in the case of emergencies or malfunctioning of the aircraft, and therefore in the case of out of the norm or high risk events.

Many of the flight systems installed in an aircraft are automated but anyway a human external intervention in case of emergency is possible.

A particularly felt problem concerns the determination of responsibilities, in a correct manner, in case of malfunctioning of a predetermined flight apparatus/system.

The issue is extremely complex since on such an apparatus different actora intervene or can intervene, and all of them with different tasks.

For example, we can consider the design (potentially subject to defects), the functioning tests, the various programmed maintenance services, or the daily use by the pilots.

For the new devices that are not yet operative, and therefore in design and/or test phase, the issue is obviously still more complex since there is no objective evaluation data with reference to possible breakdown events during their operative life.

The malfunctioning can therefore depend, in a hardly foreseeable way, from one or more subjects involved, so it results to be difficult to foresee the respective responsibility or percentage of responsibility in case of malfunctioning. In particular, it is difficult to foresee statistically in accordance with which percentages the responsibility can be distributed in case of malfunctioning. This is valid both for the new technologies which still have to enter in use and are therefore in the realization phase, and for those that are already in course of use.

All this has a significant impact both on the flight safety and also in terms of costs that have to be afforded by the various companies, the whole influencing safety again.

In fact, in the case in which it cannot be determined beforehand with certainty which and whose responsibilities can intervene on the malfunctioning (and therefore the possible percentages of allocation of the responsibilities) , many times the use of such a technology is abandoned.

This has obviously a significant impact on the flight safety, because the use of a determined apparatus could contribute for sure on other fronts, guch as the ecological one of fuel saving, etc., according to the specific technology in use. Nevertheless, when such a technology does not give certainty about correctly identifying the responsibilities in case of malfunctioning, this conducts for sure to an abandonment of the same with impacts that, as said, are everything but beneficial.

In particular, the aspects of attribution of responsibility associated with a new complex and automated technology should be taJcen into account and analyzed during the definition of the technology itself, making that the design and development process be oriented to design the new technology in such a way as to render it not just efficient for the intended purposes in operative, technological and safety terms, but also of attribution of responsibility .

An indetermination or impossibility to determine a correct attribution of responsibility often causes the abandonment of such a technology.

To consider the legal aspects of attribution of responsibility during the design process of the new technologies, rather than at the end of it, would allow to strengthen the design and development process of the new technologies themselves, avoiding at the .same time to incur undesirable epilogues off schemes of sub-optimal attribution of responsibility (with consequent insurance expenses) or of abandonment of the technology itself by the effect of the missing agreement on the scheme of responsibility to adopt. An example of this is the AHS (Automated Highway System) technology in the technical field of earth transport and that foresaw the realization of road lanes dedicated to earth vehicles without a driver, and therefore drove in an automated manner, the whole to improve transport safety.

The project has been abandoned because it resulted to be difficult to make a prevision of possible distributions of responsibility^' in case of malfunctioning and therefore, in the end, it would have never been approved and would have never become operative.

In addition* it could even happen to complete a design of a predetermined device to then not be able to render it operative precisely because the flow of responsibility in case of malfunctioning cannot be determined and this, obviously, implies a very big further economic loss for the company that has commissioned the realization thereof.

The same can be said also for devices/systems currently in use which, by rendering difficult the determination of responsibility, are hardly adoptable and therefore destined to a progressive abandonment, even if efficient and useful.

The whole always at the expense of costs and safety. Disclosure of invention

It is therefore the aim of the present invention to realize a method of analysis for determining responsibilities that solves said technical inconveniences .

in particular, it is the aim of the present invention to provide a method that allows, in a sufficiently precise manner, to determine and foresee a correct percentage indicative of a distribution of responsibility in case of malfunctioning of an aircraft system/apparatus, in such a way as to allow a use of such a technology rather than its abandonment (both in the design phage and in the implementation phase) .

These and other aims are thus reached in accordance with the present method for determining a percentage of responsibility of a subject, in case of malfunctioning of an apparatus, preferably an aircraft apparatus, as per claim 1.

Such a method foresees the phases of:

- A) Insertion, in electronic format in an electronic processor (1), of one or more apparatus_data comprising information relative to the apparatus under examination and/or one or more subjects involved in the design/use/maintenance of such an apparatus;

- B) Determination, by the electronic processor, of a level of automation of the apparatus through a comparison between at least a part of the apparatus _data previously inserted and one or more similar apparatuses;

- C) Extrapolation, in electronic format, of one or more Obligations_of_Action which are correlated to the level of automation determined In phase B) ;

- D) Visualization by the electronic processor of one or more responsibility_maps relative to one or more subjects inserted in phase A) ;

- Said maps being browsable by the user in such a way that the user can select one or more paths on the basis of the Obligation/s_of_Action determined in phase C) , for each path corresponding a percentage of responsibility.

In such a manner, the pre-fixcd aims are reached by the present invention. In particular, the insertion of data relative to the apparatus under, examination, for example its functionality, allows the electronic processor to select, for instance with a search by key word, electronic documents relative to similar apparatuses visualising a level of automation. To each automation level correspond obligations of action already codified by regulations and that are thus visualized. The software is able, therefore, in a precise way, to select and to support the user in the determination of all the correct obligations of action relative to the case under examination.

The subsequent visualization of the maps, which are browsable, allows the user to select one or more paths on the basis of the obligations of action that the computer has found.

In that sense, the operator has a convenient instrument that in a safe and precise way is able to schematize and generate a result of responsibility in the form of a mathematical percentage.

Further advantages can be deduced by the dependent claims .

Brief description of drawings

Further features and advantages of the present method, as per the invention, will result to be clearer with the description that follows of one of its embodiments, made to illustrate but not to limit, with reference to the annexed drawings, wherein:

Figure 1 shows schematically a connection of a PC to a centralized server of management of said method;

- Figure 2 shows in a flow chart the essential phases of the method implemented by the central server;

Figure 3 shows a more detailed flow chart relative to the phase of creation of a new case of analysis, analyzed by the central server/ - Figure 4 specifies the phase relative to the insertion of specific information;

- Figure 4A specifies, in accordance with a sort of schematic flow chart, the insertion of such initial information;

- Figure 5 shows schematically the phase of determination of the level of automation and, from here, the relative "task responsibilities";

- Figure 5A shows the extrapolation of the "task responsibilities'';

Figure 5B shows a chart of identification of the level of automation;

- Figures from 6 to 9 specify diagrammes relative to the evaluation of the possible raalfunctionings;

- Figure 10 represents as a way of example one of the so- called "responsibility maps" in the form of a tree structure;

- Figuro 11 shows in detail the first level of the tree graphics of figure 10.

Description of some possible embodiments

With reference to figuro 1 a remote server 1 is described which is accessible_/ through the Internet, from any personal computer 2 or device capable of connecting to the Internet (for example also a mobile telephony device) .

The user connects to the remote server 1 and proceeds with an authentication phase, following the registration to the service,

The registration to the service, as it is well known in the state of the art, can foresee the insertion of one or more data relative to the subject and the selection of one or more passwords (for example USER_ ID and/or Password) in order to have access to the own specific area .

In this way, each subject, after entering the own dedicated area_/ can make an own specific analysis whose outcome and the various data remain in memory.

The server 1 is programmed, as described in detail below, in such a way as to process all the specific data inserted by the user, and so as to be able to extrapolate an outcome of risk on the specific case that the user inserts.

Obviously, as clarified below, the procedure is such as to guide the user in the various necessary phases (phases that will be described in detail below) .

Having said that, after entering the programme with the connection to the server 1, it is now possible to create a new case of analysis.

The flow chart of figure 2 shows the "macroscopic" phases that take to the final visualization of an . outcome report. By "macroscopic" in the present text it is intended the fact that each one of them is subdivided into specific sub-phases.

Always with reference to figure 2, the method foresees, above all, as said, a connection to the server 1 to make an authentication, which implies the insertion of the own credentials in order to access to the own specific page (for example, a User ID and/or a Password) .

At this point, the. server offers the user the possibility of initiating or resuming the analysis of a specific case, for example with reference to a new apparatus of which it is needed to evaluate the percentages of responsibility that can be allocated in case of its hypothetical malfunctioning or breakdown.

The apparatus or the system in general can obviously be of new concept, therefore not yet installed and operative, or it can be an apparatus that has already been operative for some time.

The flow chart of figure 2 shows the macroscopic step subsequent to the authentication_/ or "Creation of the new case" in which the insertion of one or more specific data is necessary.

The subsequent "macroscopic" phase, always with reference to figure 2, will be that of true analysis that will be concluded with a visualization of report and therefore of an outcome of the correctly allocated responsibilities.

The phase of creation of the specific legal case foresees the insertion of the specific data relative to the case in analysis and a specification of the same is shown in the flow chart of figure 3.

The data inserted in this phase of "creation of the case" are saved in the server to be then appropriately processed.

The data can include the insertion, for example, of the actors or subjects identified and that are involved in the design/use/maintenance of the specific apparatus in question.

The- flow chart of figure 3 shows greatly in detail such a phase, which foresees :

Insertion of information;

Identification or the level of automation; Identification of the possible malfunctionings

The phase of insertion of the data, or of "Information Insertion", can take place textually through, for example, "html forms" or similar formats (such as files generated by processors of text, charts, etc.).

Some of the insertable data are shown in the chart of figure 4. Such data can foresee information relative to the aim of the system, for example why it has been proposed and to which needs it wants to respond, as well as the description of the actors, etc. In this way, information is electronically loaded in the programme which can then be processed technically to determine a final result.

Basically, the pre-constituted chart of figure 4 contains, one or more pieces of information relative to the subjects involved in the use/maintenance/construction/certification of the apparatus as well as other pieces of information relative to the functioning and/or aim of the system.

The chart requires the insertion of some obligatory fields which, if not filled in in full and correctly, cause an error and the programme does not allow to continue.

The programme controls the filling in of the obligatory fields.

A field that requires necessarily to be filled in is that relative to the subjects involved in such an apparatus (from the person that uses it to the one that certifies it) and the functionality and/or the aim of such an apparatus. This, is because, as clarified below, such information is adequately processed by the programme in the subsequent steps, as clarified below.

in particular, an insertion element that is particularly important concerns the "actors", or all the persons that are involved in the design/realization of the system to be analyzed. The chart 4 constitutes an example of which data, relative to the actors influenced by the new technology, can be shown.

If, for instance, the technology concerns a new type of braking system, the actors that are involved directly could be pilots, controllers and maintenance officers, while those who could be involved indirectly could be the developers of such a system and the certifying bodies. Figure 4A, in a schematic manner, shows the logical flow of functioning in such a preliminary phase. The phase of insertion of the data is shown . and the PC then processes the control on them. If all the obligatory fields have bean correctly inserted the programme allows to continue. On the contrary, the insertion of the data is required again (at least the missing data) .

Always with reference to the creation of the new case the identification of the level of automation is then done, or the "Identification of the levels of automation⁰, on the basis of a taxonomy recently developed in the field of the research programme on the^' Single European Sky (the reference is: Save L., Feuerberg, B. , Designing Human" Automation interaction; a new level of Automation Taxonomy, in De Waard et al., Proc. Human Factors of - Systems and Technology 2012) . The taxonomy reports how. much the automatic system supports the human operator with respect to four fundamental functions:

- Acquisition of information;

- Analysis of the information;

- Decision making;

- Execution of the action.

To each of these functions corresponds an assembly of levels of automation (from a total of five to a total of eight) . For example, the function "Acquisition of information" comprises an assembly of five levels of automation, while the function "Execution of the action" comprises an assembly of eight levels. The various levels of automation are determined by a numerical score. The scores go from a basic level 0, which corresponds to the completely manual execution of a task, and increase to higher scores until the complete automation.

For instance, the automatic pilot of an airline supports the pilot in the function "execution of the act.ion", with respect to which presents a middle level of automation (classified with a score of four) . Et is in fact activated voluntarily by the pilot, which can monitor the course of the flight and eventually deactivate the automatic mode thereof.

A board anti-collision system, instead, supports the pilot both in the acquisition and processing of the information_/ and in the decision making. This, in fact, shows on the screen a representation of the aircrafts that are flying nearby. In this case, the support to the acquisition and processing of the information presents a high level of automation, in the specific case "five", because tho system generates and selects automatically the information to be presented on the screen from different sources .(satellite signals, radars, etc.)_/ on the basis, of pre-defined criteria at design level and unknown to the pilot. If it detects tho presence of a risk, of collision with eventual aircrafts nearby, in addition, the anti- collision system generates an alarm and proposes to the pilot a manoeuver of avoidance to re-establish the safe separation threshold. In this casa, the support to the decision making presents a medium-high level ^' of automation, in the specific case of "four", since the system decides automatically which separation action has to be executed by the pilot, from a series of options calculated automatically and not shown to the pilot.

This aspect is important for the determination of the level of responsibility since the taxonomy allows to determine exactly the allocation of the tasks between the human operator and the automatic system.

Going further into the technical detail, as said above, there exists, di per se, a regulation that rules the level of automation for apparatuses of the state of the art already existing and relative to the Single European Sky, as per the references indicated above. In particular, the taxonomy presents, further, for all the levels of automation of each cognitive function, examples of apparatuses of the known art already existing in the aircraft field.

The software; therefore, in this step, guides the user to the determination of a correct level of automation for the technology in analysis.

To do this, as per figure 5, the programme generates a textual comparison, for example by key word, between the data inserted in the preceding step with relation to, for example, the type and/or functionality of the apparatus in analysis and apparatuses of the known art: loaded inside it and anyway pre-defined at the level of taxonomy above, in such . a way as to extrapolate and permit the user to visualize the apparatuses that are more similar between them with their relative level. of automation.

An example of comparison by key word implies the extrapolation of some words in the text introduced by the user and a search of the same in the loaded texts of the known art.

This allows the user to visualize and acquire immediately the levels of automation of similar apparatuses of the known art.

At this point, as per figure 5B, the user is further guided through the insertion of such data into a specific chart, once the automation level has been determined.

The chart of figure 5B requires to show the level of automation determined previously and to provide an explanation of why a determined level for each function has been assigned, which corresponds to the description of how the functions between pilot and automatic system are allocated. From the chart the system derives the Tasks.

As in fact shown in figure 5A, at leach level of automation correspond one or more "obligations of action" defined in technical jargon as "Task Responsibilities". They are already codified on the basis of tho international procedures and correspond in the software to toxt strings that contain, for each level of automation, the indication of which actions have to be taken by the human operator.

As- shown in the example of figure 5A, a high level of automation associates strings in which actions are contained such as, for example, "Obligation to execute the maneuver of avoidance". This is the perfect example for the apparatus that, as per the example shown above, controls the presence of other alrcrafts around the aircraft on which it is installed and, on the basis of this information, suggests the pilot a maneuver of avoidance (anti-collision apparatus) . Such an apparatus is highly automated and tho pilot has to acquire the information as it is, having the obligation to execute the maneuver of avoidance suggested by the system. Such an obligation is defined at the level of the international procedures that regulate the air navigation and that, as said above, inform the task responsibilities pre-defined in the software.

In fact, for each level of automation there exist already codified such "Tasks" and therefore the software, on the basis of the level of automation inserted by the user, derives the relative "Task/s" of the case and renders them available to the user.

The use of such "Tasks" is clarified right below with reference to the responsibility maps.

In these phases the software, on the basis of the data inserted, has extrapolated a level of automation and from there one or more associated "Tasks".

The subsequent phase of the method foresees the inaertion of data relative to the possible malfunctionings, the so-called "Failure scenarios".

Such scenarios of malfunctioning can be one/ or more than one, and are hypothesized by the user in such a way as to be able to correctly allocate the responsibilities for each type of malfunctioning that can take place In reality during the malfunctioning of the apparatus.

To a piece of information of malfunctioning is associated a possible scenario of accident and from here, the responsibility is allocated.

The purpose of such a phase, therefore, is that of identifying, on the basis of the information on the functioning of the system, the possible risks of malfunctioning associated with the use of the system. Also in this phase the information is preferably inserted through html forms .

In order to support the user the programme, therefore, visualizes an assembly of "maps of classification of the possible malfunctionings" and supports the user in the identification of hypothetical cases of dysfunction of the system and/or disservice related to its use. These maps present a troe structure, which lists the possible malfunctioning on the basis of categories that are always more specific as the level descends .

Figure 6 shows the most general level of the maps of classification, showing that the possible causes of malfunctioning can be of active nature (human error or technical dysfunction) or latent (organizational or technical design error} .

As shown in the subsequent figures, for each one of the two main branches (active or latent cause) are specified in a very detailed manner the various types of malfunctioning (see for example figures from 7 to 9) . In a practical example of use, the software visualizes and allows to navigate the maps.

Such maps are explored and navigated by the user which is able in this way to reconstruct one or more cases of malfunctioning considered possible for the apparatus in question.

For example, in a board, anti-collision system a slowing down in the update of the data (technical dysfunction) could take place, furnish on the screen of the pilot an unreliable representation of the aircrafts that are flying nearby and consequently, propose a maneuver of avoidance based on non-updated data.,

A first case of analysis could be relative to:

Lowering down of the anti-collision system and collision of the aircraft.

The pilot could be induced to think, on the basis of this representation, that a certain aircraft is flying farther (or nearer) to it than what it actually is, and execute the maneuver of avoidance suggested by the system. As the acquisition of this information is very automated (as described above), it is very difficult for the pilot to question such data.

The final step foresees the use of the so-called "responsibility maps'' in order to determine a scheme of attribution of responsibility for each hypothesized scenario and that distributes this last one among the various actors involved in the design and use of the system that is the object of analysis.

This concerns the part of true analysis with reference to figure 2.

The responsibility maps present also a tree structure; as shown in an example of figure 10 and relative to the analysis of responsibility of the pilot.

These are pre-constituted. They have been developed on the -basis of the regulations, the doctrine and the law on responsibility in the European context in the field of aviation, and contain the association to the pertinent international laws. Each map reproduces the argumentative process that brings to the determination of the responsibility, or less, for a given actor, be it a natural person or a legal person. There is the map relative to the responsibility of the pilot, the map relative to the responsibility of the air traffic controller, the map relative to the certifying body, to the technology producer, etc. (the example of figure 10 refers to the pilot) . The programme extrapolates and presents to the user one or more responsibility maps, on the basis of which actors have been inserted and mentioned in the phase of creation of the case.

As said, figure 10 represents a map relative to the case of the pilot, though the programme extrapolates and visualizes the maps relative also to the other actors inserted in the previous step.

In the case mentioned above, relative to the malfunctioning of a board anti-collision system, which presents a non-updated representation of the aircrafts that fly nearby with relative crash of the aircraft, the pilot would make a wrong maneuver on the basis of that representation, and would cause an accident.

The actors involved in the legal analysis of this case are: the pilot, the air traffic controller, the technology producer and the certifying bodies. The programme furnishes in automatic the responsibility maps for each of them. The responsibility maps of the pilot, for example, help to understand under what circumstances the hypothesis that this last one is responsible can be confirmed. The main legal question, on the basis of comparative law, is to demonstrate if the behaviour of the pllot has been negligent. Through tho exploration of the subsequent levels of the map arguments to support (or less) such a hypothesis are Identified.

In this example, the pilot has not behaved in a negligent way, since he has followed the instructions given by the board anti-collision system.

More in particular, the enlargening of figure 10 (or figure 11) shows the initial part of the graphics in which the first box, ^Responsible Pilot", is highlighted.

Wo pass onto the underlying branch. To pass from a branch to an underlying branch it is necessary that all the- conditions of the branch under examination are verified*

The user analyses the boxes 1A-a, ΙΑ-b and 1A-c. It is exactly in this phase that the "Task" that the programme has selected for the level of automation previously determined intervenes.

The "Task" that is furnished and visualized by the programme supports the user in sliding and ticking the appropriate boxes of each map, in such a way that the software can correctly calculate, for the hypothesized case, a possible percentage of responsibility.

Always in the same example of the anti-collision system with a high level of automation, or 5, the "Task" can for example indicate an obligation in having to execute a manoeuver of avoidance for separating itself from an aircraft nearby (or obligation of the pilot in having to trust the information received by the instrument) . This translates in the fact that the pilot is obliged to follow the maneuvers on the basis of the information received by the anti-collision device. In that sense, the user that navigates this map can tick the relative box ΙΑ-a ("there has been damage to third parties") , but not the remaining 1A-b and 1A-c since, for example, in ΙΑ-b it is indicated that there has been an imprudent behavior of tho pilot. In the example in course, the task, having indicated an obligation for the pilot to execute a pre-determined maneuver (task furnished by the programme on the basis of the previous level of automation determined) , it is obvious that the user will not be able to tick the box ΙΑ-b and therefore the analysis of responsibility closes at such a I" level and does not proceed for the underlying levels. For each level, the programme has a certain percentage of responsibility memorized and obviously increasing.

Stopping in this case at the first level the level of responsibility that emerges ^' (and that is then printed in the report) will be low, for example of 15%. This means that the probability that the pilot (or the airline on his behalf) is called to compensate damages is very low.

Basically, for the hypothesized case:

- Anti-collision system - technical malfunctioning (delay in the processing of information) - scenario of "collision" accident; the pilot will result not much responsible.

Not only is the procedure exactly the same for the other eventual subjects, but, always in accordance with the same methodology, for the same apparatus other possible scenarios of malfunctioning - accident can be hypothesized and therefore have further allocations of responsibility.

The final report furnished is therefore a report (for example in the form of a chart) that shows for the apparatus under examination for each scenario or malfunctioning and accident hypothesized a percentage of responsibility of the subjects that can be allocated. This allows the verification, a priori and before the implementation of a new apparatus, to hypothesize with a good mathematical certainty a correct allocation of responsibility, allowing also to modify before the design where the outcomes of responsibility would render such a technology not viable.

Going back to the above case, as said, with the same methodology we can now analyze the responsibility of the other actors involved.

For example, the producer of the board anti- collision system. The legal question to demonstrate, in this case, is if the system presents a production deffect. Through the levels of the map relative to the producer it is possible to identify the argumentations to support this hypothesis and therefore the level in percentage of responsibility. In the same way, the procedure is the same for the other actors involved.

As said, to the path identified in each map corresponds a percentage of responsibility relative to the legal risk associated with said data of the actor, that is the probability for that data of the actor of being called to compensate damages in the specific case under analysis.

The programme is capable of computing the distribution of the responsibility among tho various actors ,

If, for example, there is a hypothesis of damage (collision) derived from the fact that the pilot does not pay attention to the indications of the board anti- collision system, and an accident is verified afterwards, the probability will be extremely high that the pilot is considered responsible ( and consequently, the airline is called to respond for the damage) . However, if the behavior of the pilot, even if unusual, could reasonably be considered necessary to avoid greater risks, the probability that the pilot is considered responsible (and, consequently, the responsibility of the airline will be limited to the maximum sums established by law) will descend to a very low level.

If the programme hag also the probability of verifying determined risk scenarios, for example on the basis of profiles of risk officially consolidated, by combining the responsibility of the risk and the conditioned probability that given the risk there is the responsibility, it will be capable of determining the unconditioned probability of the- responsibility.

In the moment in which, on the basis of the specific case under analysis, a determined scenario is indicated, the software produces the percentage of responsibility pre-defined for that specific scenario.

As said, the final phase foresees the visualization of a report in which, on the basis of the data inserted, the programme produces a graphics and a summary text that summarizes all the legal responsibilities of the various actors and which the information of context defined for such responsibilities are.

Claims

CLAIMS 1. A method for determining a percentage of responsibility of a subject, in case of malfunctioning of an apparatus, preferably an aircraft, the method foreseeing the phases of:

A) Insertion, in electronic format in an electronic processor (1), of one or more apparatus_data comprising information relative to the apparatus in exam and/or one or more subjects involved in tho design/use/maintenance of such an apparatus ;

B) Determination, by the electronic processor, of a level of automation of the apparatus - through a comparison between at least a part of the apparatus^_data previously inserted and one or more similar apparatuses;

C) Extrapolation, in electronic format, of one or more Obligations_of_Action which are correlated to the level of automation determined in phase B) ;

D) Visualization by the electronic processor of one or more responsibility_maps relative to one or more subjects inserted in phase A) ; ·

Said maps beings browsable by the user in such a way that the user can select one or more paths on the basis of the Obligation/s__of_Action determined in phase C) , for each path corresponding a percentage of responsibility.

2. A method, as per claim 1, wherein said phase of insertion of one or more apparatus_data is guided by the electronic processor which verifies the filling in at least of all the foreseen obligatory fields.

3. A method, as per claim 1 or 2, wherein said insertion of one or more apparatus_data is guided by the electronic processor through the visualization of a chart comprising one or more fields to fill- in.

4. A method, as per one or more of the preceding claims, wherein said phase of comparison in the electronic processor between at least a part of the apparatus_data previously inserted and one or more similar apparatuses foresees a comparison between the electronic text files relative to the apparatus__data and one or more documents in electronic format of similar apparatuses.

5. A method, as per claim 1 or 4, wherein said comparison is made through the use of one or more key words^'.

6. Ά method, as per one or more of the preceding claims, wherein following said comparison the electronic processor visualizes the levels of automation of the similar apparatuses selected and of which the level of automation is known.

7. A method, as per one or more of the preceding claims, wherein the Obligations_of_Action are text files that are visualized by the electronic processor, said Obligations__^of_Action being text files pre-constituted on the basis of the level of automation determined.

8. A method, as per claim 1, wherein said responsibility maps are pre-constituted and are developed according to a treo structure.

9. A method, as per one or moro of the preceding claims, wherein said responsibility_maps foresee a plurality of boxes that determine one or more paths, each box visualizing a piece of information correlated to the hypothesis of the malfunctioning and/or to the action executed by the subject of which the responsibility wants to be determined.

10. A method, as per one or more of the preceding claims, wherein each · box of the responsibility_maps can be ticked by the user/ the electronic processor calculating a relative percentage of responsibility on the basis of the boxes ticked.

11. A method, as per one or more of the preceding claims, wherein the electronic processor produces a complete report.

12. A method, as per one or more of the preceding claims, wherein a preliminary phase of access through the Internet to said electronic processor (1) is foreseen.

13. A programme for electronic processor comprising one or more computing codes suitable for executing one or more phases of the method of which to one or more of the preceding claims from 1 to 12, when the programme itself runs on an electronic processor.

14. Computer programme of which to the claim 13 characterized in that it is incorporated in a computing support.

15. A computer characterised in that; it foresees a software as per claim 13 or 14.